On Tue, Feb 7, 2012 at 7:33 PM, Ondrej Mikle <[email protected]> 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 _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
