[tor-dev] DNS-over-HTTPS (DOH) in Firefox/Torbrowser
Matthew Finkel
sysrqb at torproject.org
Wed Jul 1 23:29:14 UTC 2020
On Sun, Jun 14, 2020 at 08:19:13PM +0200, nusenu wrote:
> Georg Koppen:
> > nusenu:
> >> Hi,
> >>
> >> since Mozilla did tests [0] on DOH [1] in Firefox I was wondering
> >> if Torbrowser developers have put any thought into that as well?
> >
> > Actually, the study did not get done yet. The start date is scheduled
> > for June 4th, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1446404
> >
> > We'll look at the code in the coming weeks when doing our audit for
> > ESR60 and we'll follow the Mozilla experiment closely. Right now we
> > don't have plans to enable DOH in Tor Browser 8.
>
> Since we are discussing this topic in the "Support for full DNS resolution and DNSSEC validation"
> thread, I wanted ask whether there have been any updates on this topic since and how
> you think about making use of DoH in Tor Browser?
Sorry for the delay. The short answer is "we aren't planning on making
any use of DoH in Tor Browser".
>
> I'd be interested to write a design document, but if you see a blocker
> then we probably shouldn't be putting any resources into it.
The (slightly) longer answer is that, at face value, there are many
seemingly obvious disadvantages to Tor Browser using DoH for DNS
resolution and there aren't many advantages. I didn't follow the DNSSEC
thread, but I just skimmed it, so I apologize if I reiterate some
already mentioned points.
Using DoH has the same disadvantages as the tor client sending its own
DNSSEC query (instead of letting the exit relay perform the resolution).
I see Roger mentioned the concern about additional latency and
round-trips, so I won't restate that.
Your comment about achieving hostname-confidentiality is interesting,
but (as with most arguments about ESNI+DoH) this assumes/requires
multi-tenant service providers (and centralization, in general). We can
get a similar outcome by including a list of providers that support
domain fronting and Tor Browser doing some intelligent substitution in
the TLS handshake. This would be very hacky, though.
The main concern I have is that DoH is not fit for Tor's purposes.
Instead of trying to re-use a new level of abstraction, we can get a lot
of the same benefits by improve the adoption and usability of onion
services.
With all of this being said, I am curious to see measurement results
that compare connection times where a) the exit relay handles the DNS
resolution, and b) where Tor Browser uses a DoH server and then requests
a connection to a raw IP address.
More information about the tor-dev
mailing list