On Fri, 2020-05-15 at 14:30 -0400, Roger Dingledine wrote: > On Fri, May 15, 2020 at 05:39:23PM +0200, Christian Hofer wrote: > > Final remarks. When I started, I didn't expect it to get this big, > > and > > frankly, if I had known before, I might not have even started. > > However, > > I learned a lot about DNS, DNSSEC, SOCKS, and Tor. So even if you > > decide not to merge it, it was not a waste :-) > > Hi Christian! >
Hi Roger! > Given the above learning, let me ask you a related question. Or maybe > rather, a question about an alternative design. > > As I understand it, the design in your patch is basically to let the > Tor client talk via Tor to an authenticated dns server that the > client > chooses, and do the DNS interaction to satisfy itself that the DNS > answer > is correct. > Yes. Exactly. > And because the DNS server is a different destination than the > original > stream destination, this requires another round-trip through Tor, for > doing the resolve? > > And maybe it's way worse than that, because to do DNSSEC properly, > you > need to go up the chain, with a new round-trip over Tor for each link > in the chain? > Yes, that is a big concern. However, that is the trade-off you have to consider (performance vs security). > Whereas in the current Tor design, we have no extra round-trips for > the > DNS component, because the client sends the hostname in the BEGIN > cell, > and the exit relay resolves it and connects, and then sends the IP > address back in the CONNECTED cell in case the client wanted to know > it. > > To me, extra round-trips over the Tor network in the critical path of > "user clicks and waits for the website to load" are really bad, and > need a really good argument for being there. Given that DNS is only > one > piece of the connection -- after all, the exit relay can still route > you > somewhere else -- it's hard to see how this case brings enough > benefit > to justify the extra round trip(s). > I understand. > Ok, with that as a preface, here is an alternative design: the Tor > client sends the hostname to the exit relay, along with a request for > dnssec proofs. The exit relay uses its own dnssec server to convince > itself that its answer is right. Then it returns the IP address in > the CONNECTED cell as it does now, and also it returns a set of > dnssec > answers that the client can use to reconstruct the dnssec interaction > and convince itself of the result too. > > This design adds no extra round trips (yay), but it requires a notion > of > "dnssec chain stapling" that I think doesn't entirely exist yet. Alex > points me to a long-expired IETF draft from agl on the topic: > https://tools.ietf.org/html/draft-agl-dane-serializechain-01 > and I don't know if there is newer progress. > Sounds very interesting. This would definitely save a lot of time (round trips). > I would also worry about the overall size of the stapled answers -- > if we > add another 50KBytes to every stream interaction in Tor, that's > probably > not worth it. Whereas adding another 1KByte could be a great > tradeoff. > > Yet another twist here is that it's hard for the client to cache > answers, > or to cache intermediate certs in the chain, because changing > behavior > based on cached answers can reveal the client's past browsing > history. > For my proposal this is true. For your proposal if you get all DNS messages required for performing chain validation in one big batch you don't have to cache intermediates but only the resulting DNS record and caching would be feasible. > Do these goals make sense? :) > Yes, I think this would be a big improvement. Let me know if you plan to start working on a design / implementation to get this done. > Thanks! > --Roger > BR Christian > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
