[tor-talk] Tor with ttdnsd and unbound

[Ondrej Mikle]

On 04/29/2012 07:01 PM, Jacob Appelbaum wrote:
> On 04/29/2012 12:15 PM, Ondrej Mikle wrote:
>>
>> I wrote a HOWTO for DNS/DNSSEC over Tor with unbound+socat (IMHO if you're using
>> unbound, drop ttdnsd altogether):
>>
>> https://labs.nic.cz/page/993/dnssec-validation-over-tor--linux-/
>>
>> Click 'English' on top of the page if you get Czech version (it takes language
>> preferences from headers sent by browser; Referer sending must enabled in
>> browser in order the language switch to work).
>>
> 
> I'm the current maintainer of ttdnsd and I fully support using something
> that isn't such a hack.
> 
> I know that Paul Wouters and another unbound developer hacked together a
> udp/tcp listener that only made outbound TCP connections. I think I made
> some notes in the ttdnsd git repo at one point.

The 'tcp-upstream' together with 'forward-zone' settings accomplish that.

> There was a patch that needed to be applied to unbound but I believe it
> is now merged. If that is the case, I think that unbound and either
> TransPort + iptables, socat, torsocks and unbound would be the best path
> forward.

That would work, but we need to deal with circuit correlation (from different
applications). For example, your IM client will query:

IN SRV _xmpp-client._tcp.nic.cz

Now that single query will put you into a very small group, "tagging" all the
other queries from the circuit. Not quite sure how much similar is it to viewing
a little-visited site over Tor.

>>> [1] https://lists.torproject.org/pipermail/tor-dev/2012-March/003341.html
>>
>> The above proposal/implementation will take a while to finish, I've run into
>> some technical quirks that need to be resolved (in order to have it working
>> reasonably fast and not shoot yourself in foot with some stupid design/coding
>> mistake).
>>
> 
> Oh?

So far I have the impression that every approach is like: "You might shoot
yourself in the foot, but at least you can choose which toe it will be, if any."

Short summary:

1. Circuit correlation, as in above example. We need some "demultiplexer" that
would send unrelated queries over different circuits, e.g. a permanent mapping
PID of querying application->SocksPort/TransPort, something along
IsolateClientProtocol.

2. Deriving/guessing client's local DNS cache state from what queries are sent
and which are skipped (i.e. what sites user visited already). Shouldn't matter
too much for simple queries without many CNAMEs/DNAMEs in answer (typical RR has
TTL in order of hours, thus clients are expected to requery). With queries
having many CNAMEs/DNAMEs in answer spanning over multiple zones (various CDNs
usually), it could leak some information.

3. Nick wanted to integrate libunbound event loop with Tor's event loop [2].
That will also influence round-trip time, especially in the cases with many
CNAMEs/DNAMEs (many zones => many DS/DNSKEY queries).

Issues 2. and 3. could be alleviated by something like Adam Langley's DNSSEC
stapling [3], but the stapling is already complex enough and doesn't even take
into account NSEC/NSEC3 yet.

We're doing some mass DNS RR scans to get some statistics on things like sizes
of responses, DNSKEYs fetched, number of zones traversed through CNAMEs/DNAMEs
(hopefully the result will be better than "majority of men have above-average
number of limbs").

>> That's also the reason I decided to try the "DNS as hidden service over TLS"
>> approach.
>>
> 
> I think this doesn't scale very well but it's never the less quite
> interesting as well!

Aside from scalability, DNS hidden service is quite hard to hide (outside
communication necessary) and there's the circuit correlation as well (so a
demultiplexer sending to distinct DNS servers necessary).

But it can be deployed without changes in Tor and a bug in unbound won't
compromise Tor relay. I just thought - let's give it a try and see where it
takes us.

[2] https://lists.torproject.org/pipermail/tor-dev/2012-March/003360.html
(comment under "5. Implementation notes")
[3] https://tools.ietf.org/html/draft-agl-dane-serializechain-01

Ondrej