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

[nusenu <nusenu-lists@xxxxxxxxxx>]

> 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.

also expired but newer
https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/
 
> 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.

I share your concerns on performance (additional round trips) and caching and I find it also important
to note that in the context of tor browser (probably the main use case of tor)
encrypted DNS (confidentiality) is more relevant than DNSSEC (integrity), 
especially as soon as ESNI becomes reality. 
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
That will allow for using tor exits without disclosing the visited domain to the exit relay
and no more issues with exits with broken DNS.
DNSSEC would still be valuable for TLS verification but DANE for https does not appear to be a thing.

Attachment: signature.asc
Description: OpenPGP digital signature

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