[tor-dev] Tor and DNS

[Nick Mathewson]

On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle <ondrej.mikle at gmail.com> wrote:
> On 02/07/2012 07:18 PM, Nick Mathewson wrote:

>> part of the relay cell header should already fulfill this role, if I'm
>> understanding the purpose of "ID" correctly.
>
> You're understanding the purpose correctly. I thought that more requests could
> be used in a single stream, but after re-reading tor-spec.txt, we can just use
> StreamID the same way as for RELAY_RESOLVE(D). So let's ditch the ID.

Agreed.  It means you can only have 65536 total streams and requests
inflight per circuit at a time, but that's a pretty generous limit.

>> Like Jakob, I'm wondering why there isn't any support for setting flags.
>
> See my response to Jakob. I don't think it's worth to use anything else than
> flags 0x110 (normal query, recursive, non-authenticated data ok) with DO bit
> set. Unless there is a really good reason for other flags, that would only have
> potential to leak identifying bits.

I can't think of one offhand; I had at first thought that
non-recursive queries were good for something, but I'm not really sure
what.

[...]
> Your example with 1200 byte reply is correct.
>
>> Also, in this case,
>> I think the length field in this packet _is_ redundant with the length
>> field of the relay cell header.
>
> The inner "length" might be useful in case we wanted to add an extra field
> (maybe not a good idea for some other reason, like confusing older OP if we did
> add a field later?).

I think if we want an extra field in the future, we want to put it
after the end of the response (that is, after total_len), rather than
having it be optionally in every cell.

>> I think the total_len field could be replaced with a single bit to
>> indicate "this is the last cell".
>
> "End" bit would work, but I find it easier to know beforehand how much data to
> expect - we don't have to worry about realloc and memory fragmentation. Client
> could deny request if claimed total_length is too high right away (or later if
> OR keeps pushing more data than claimed).

Hm. If so, maybe total_len only needs to be in the first cell then.

> That also means AXFR/IXFR would be off limits (I'm OK with that).

Me too.

[...]
>> Initial Questions:
>>
>> When running in dnsport mode, it seems we risk leaking information
>> about the client resolver based on which requests it makes in what
>> order.  Is that so?
>
> Yes. For example, validating vs non-validating resolver is very easy to spot. An
> attacker eavesdropping on exit node might have it harder due to caching in
> libunbound, but malicious exit node can spot validating resolver just by the
> fact that it's asking for DS/DNSKEY records.
>
> Thus client-side validation when using DNSPort or SOCKS resolve must be on by
> default.
>
>> How many round trips are we looking at here for typical use cases, and
>> what can we do to reduce them?  We've found that anything that adds
>> extra round trips to opening a connection in Tor is a real problem for
>> a lot of use cases, and so we should try to avoid them as much as
>> possible.
>
> Requiring client-side validation for A/AAAA in RELAY_BEGIN is pointless (would
> only make it slower), client cannot check where exit node connects and
> eavesdropping attacker can easily know which DNS request belongs to DNSPort
> request and which to RELAY_BEGIN (that's true in current implementation as well
> - if TCP connection does not follow, it's DNSPort/SOCKS resolve request).
>
> So no additional overhead for RELAY_BEGIN.
>
> Case of DNSPort queries - example for addons.mozilla.org with empty cache:

Hang on, is each one of these a *round trip*? I don't think so.  That
is, you don't need to get the answer for the A query before you do the
other lookups; the client can launch them all at once.

Having extra queries isn't a huge problem; it's having extra round
trips specifically that would hurt.  From a cursory look, it doesn't
seem like we're adding any extra round trips here.

I wonder, do we want to add a "resolve and connect" mode to
relay_begin, as discussed elsewhere in this thread?

-- 
Nick