DNSCHAT-2: Build Proof of Concept

Made a couple of minor changes to the protocol described in DNSCHAT-1 - details are in the attached file.

The resulting interface is incredibly basic - I've not really put much effort into look and feel - but the system works. Did briefly tinker with Urwid to look at creating a more IRC feel, but as I'm not planning on building this beyond the PoC decided it wasn't worth the effort.

The resulting DNS Queries take the following format

{Sn}.{Sid}.{N}.{TN}.{msgstring}.endpointDomain

Where

- Sn = Sender ID - an arbitrary numerical figure used to identify the user (can be set manually, otherwise changes between sessions)
- Sid = Sequence ID - A numerical identifier for the current sequence of messages, increases incrementally
- N = Sequence Number - Used to identify message ordering within each despatch of messages
- TN = Total number of messages in the current despatch
- msgstring = hex encoded ciphertext

And there are a couple of trade-offs made on the basis that they weren't necessarily worth solving in a PoC.

- The pattern used is easily identifiable
- The Regex used to identify relevant traffic is incredibly simplistic

Although I've not made use of it, user ID (Sn above) 0 is reserved for 'system' messages - so could be used to generate a notification that a user has joined the chat. It could also be used to auto-negotiate a session encryption key, if a little thought was put into it.

The existing functionality works in two deployment scenarios

- Direct Peer 2 Peer (i.e. specifying each other's IP's as the resolvers with -r)
- Via intermediary resolvers (i.e. each end is sat somewhere on the traffic route for a real nameserver and queries are sent to an open resolver such as 8.8.8.8)

The potential OpSec mistakes that could be made were identified in DNSCHAT-1, and still stand.