DNSCHAT-1 - High Level Design ================================ This document is intended to give a high level overview of the DNSCHAT Proof of Concept. Although the communication protocol laid out will be adhered to as closely as possible, it's quite likely that elements of it will need to change as the system is developed Aim ---- The aim of the system is simple - to enable multiple users to communicate, using DNS Requests as the transport protocol. There are, of course, some usability issues associated with this, however the aim is simply to prove that it is not feasible to intercept all communications, at that attempts to monitor the Internet usage of a populace achieves nothing but privacy invasion. Although encryption is used to protect the communications, the reasons for using DNS requests as the transport are as follows - The sheer volume of DNS requests made every day provides a good cover - Any open resolver can be used to disguise the source from an adversary monitoring the endpoint Given the sheer number of open resolvers on the Internet (whether deliberate or through misconfiguration), it's not viewed as particularly likely that even a State level adversary could monitor at the resolver - though individual ones may be compromised - thus both the source and the endpoint need to be monitored The downsides of course, are - You need to run a DNS server (or at least be able to capture traffic destined for one) - No chat history etc There are certain other restrictions which are known, but will likely be disregarded on the basis of this being a proof of concept rather than a complete system - The domain patterns used by the requests will likely be identifiable - There is a need to exchange keys prior to communication - There is a need to exchange details of end-points prior to communication Although the first may be addressed, the latter two likely will not be - the aim of the project is to prove a point, and not to provide a ready-made solution. Implementation ---------------- The PoC implementation will essentially be a multi-threaded Python script - Thread 1 - use Scapy to capture incoming messages - Thread 2 - Decrypt and Display messages captured by Thread 1 - Thread 3 - Capture input, encrypt and despatch messages Although a 'real world' implementation would probably include some flexibility to help evade detection, the format of the DNS lookups performed will be A{N}.{TN}.{msgstring}.endpointDomain Where N is an indicator of which part of the message this request relates to, TN is the total number of requests being used to send the current message, and {msgstring} is the payload. Dataflow ---------- Upon input, a message string will be processed as follows - Timestamp embedded (Epoch?) - Encrypted (probably with a symmetric key as this is a PoC, but using PKI would pose no additional challenge) - Cipher text converted to postscript Hex (think xxd -p) and broken into strings of no more than 61 chars - Each string is then embedded into a DNS request as {msgstring} At the recipients end, Thread 1 (Scapy) would capture the DNS request as it comes in (the source IP would now be whatever resolver was used by the sender) and pass to Thread 2 which essentially reverses the above process Use of Compression -------------------- The design assumes IRC style chat - e.g. text delivered in short messages, so compression likely isn't needed and would also mean that if parts of the message are lost, the entire despatch may be unreadable. Obvious OpSec Mistakes ------------------------ Aside from the pattern of the requests themselves potentially being identifiable, there are a number of other considerations which would need to be taken into account - All OS requests go to one resolver, DNS Chat requests to another A sane implementation of the system would probably include the ability to set a custom resolver, but to capitalise on the volume of DNS traffic leaving the average network, using the OS configured DNS resolver would be a saner option - it'd look quite odd if all DNS traffic was going to OpenDNS, except for DNSChat traffic, going to 8.8.8.8 Other Considerations ---------------------- There are a range of other considerations which would need to be made in a real-world deployment, though some simply come down to the encryption technology used (in the PoC, likely PGP). - Perfect Forward Secrecy - Participant Isolation (i.e. 3 people in a 'room', but 1 cannot see 1 of the others) Although there's no aim to address it in the PoC, enabling transfer of files would also be a likely requirement of a real-world deployment. This should (in theory) be incredibly straightforward as the base communication concept of DNSCHAT is identical to the techniques used for file exfiltration via DNS.