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