Re: [tor-dev] Support for full DNS resolution and DNSSEC validation

[Roger Dingledine <arma@xxxxxxxxxxxxxx>]

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

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev