Re: [Doh] Mozilla's plans re: DoH

"Ralf Weber" <> Wed, 27 March 2019 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EC00120094 for <>; Wed, 27 Mar 2019 16:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3kzlJpUzw1vH for <>; Wed, 27 Mar 2019 16:16:33 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:a0:322c::25:42]) by (Postfix) with ESMTP id 941D5120058 for <>; Wed, 27 Mar 2019 16:16:33 -0700 (PDT)
Received: by (Postfix, from userid 107) id 5D1945F4120F; Thu, 28 Mar 2019 00:16:32 +0100 (CET)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 356765F4039B; Thu, 28 Mar 2019 00:16:28 +0100 (CET)
From: "Ralf Weber" <>
To: "Eric Rescorla" <>
Cc: "DoH WG" <>
Date: Thu, 28 Mar 2019 00:16:26 +0100
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Doh] Mozilla's plans re: DoH
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Mar 2019 23:16:38 -0000


On 27 Mar 2019, at 10:16, Eric Rescorla wrote:
>     1. We have implemented DNS over HTTPS [RFC8484] and would like to
>     deploy it by default for our users. We intend to select a set of
>     Trusted Recursive Resolvers (TRRs) that we will use for DoH
>     resolution. TRRs will be required to conform to a specific set of
>     policies intended to protect user privacy. We’re still refining 
> the
>     final policy but we expect it to roughly match the one that 
> Cloudflare
>     has already agreed to use
>     (
>     we expect the initial set of TRRs to be small, we’re interested 
> in
>     adding new providers who are able to comply with these policies.
As said on the mic in the IETF DOH side session having a small list of
providers will be a disservice to privacy. My colleague Jon Reed just
counted the distinct IP addresses from resolvers we see to one of our
service at Akamai over a day. It was 2.64 million. Having millions of
different entities (or tens of thousands if you assume some of these
will be run by the same entity) seeing the user traffic is far better
privacy than have some large US cloud providers getting all of it,
as at the moment these would be the only choices.

And as another colleague of mine, Erik Nygren, said there is a cost
associated of running such TRR at Internet scale, and companies usually
don’t spend money without expecting a return on their investment.

For ISPs the case is clear they get money and have a contract with
the user and want to provide a good service, possibly better then
there competitor (in a lot of european countries there are regular
tests on the speed and service ISP provide).

For the cloud providers the case is not so clear, but looking at
the published privacy policies of Cloudflare and Google neither of
them say that they will not look at the data, and 24 hours is a lot
of time to convert it to get it into some machine learning, but
having looked at lots of DNS data over the last decade even without
the IP address this data, or the result of the analysis of the data
has value.

So to sum up I think opting in the users by default to a couple of
big mostly US based cloud providers is a bad idea. If the interest
really is in getting a secure private resolution for the user then
reaching out to the ISPs and getting them to work with you IMHO is
a better way than declaring them the attacker.

>     3. Copies of Firefox will be configured with a set of TRRs. 
> Different
>     regions may have different TRR sets or different defaults. In 
> addition
>     we may have DoH/TRR on by default in some regions and not others,
>     especially initially.
How do you decide which region the user is in? Does it move or is it 
on the locale setting?

>     4. The user will be informed that we have enabled use of a TRR and
>     have the opportunity to turn it off at that time, but will not be
>     required to opt-in to get DoH with a TRR.
>     5. Any given client will automatically select a resolver out of 
> that
>     set and use that for all resolutions [with the two exceptions 
> noted
>     below.]  At any time, the user will have the option to select a
>     different resolver out of the list, specify their own resolver, or
>     disable DoH entirely.
So the application provider gets to decide who does get to see all the
user data, or will the use have to select one and as stated repeatedly
most users will not be able to make that informed decisions. I don’t
think anyone has problem of an informed user selecting what he believes
is his best choice for resolving, we have that today already. But per
default switching the resolution and thus all the browsing data that
the user generates (even in private mode ;-) to a third party the user
doesn’t have a contract with is the wrong way IMO.

So long
Ralf Weber