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!
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.
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?
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).
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.
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.
Do these goals make sense? :)
Thanks! --Roger