Christian Hofer:
On Sat, 2020-05-16 at 01:37 +0200, nusenu wrote:
Alexander Færøy:
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups.
I'm also in favor of this approach, and you can do this today with no code changes to tor at all.
CF demonstrated it even before DoH/RFC8484 was finalized: https://blog.cloudflare.com/welcome-hidden-resolver/
Do you have DNSSEC validation in this approach?
That is up to you. If you use a stub resolver that has DNSSEC support (like stubby) you have DNSSEC validation.
- 1 for DoT and DoH over tor, especially due to the DoH
implementation that is available in firefox (it would still require work on stream isolation and caching risks to ensure the usual first party isolation). In terms of achieving a big improvement on tor browser users in the context of DNS this would be the most effective path to spend coding resources on in my opinion.
It seems that Firefox's DoH implementation does not employ DNSSEC validation, see [2]. They trust CF doing it for them. Be careful here.
I'm aware that firefox does not perform DNSSEC validation. I don't think the tor project would enable DNSSEC in Tor Browser without a good use-case or a (future) TLS extensions solving the latency issue. Since DANE for HTTPS does not appear to be a thing and there is no DANE support in firefox I'm also wondering about the specific use-cases for DNSSEC in Tor Browser.
Furthermore, there are privacy concerns about additional metadata regarding the use of DoH (agent headers,
solved since https://bugzilla.mozilla.org/show_bug.cgi?id=1543201
language settings,
solved since https://bugzilla.mozilla.org/show_bug.cgi?id=1544724
and cookies)
I don't think firefox sends cookies in DoH requests.
I'm still curious about the underlying threat model and use-cases (my first questions in this thread), since that would help with trying to understand what you are trying to achieve.
kind regards, nusenu