On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle ondrej.mikle@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?