Re: [Doh] Mozilla's plans re: DoH
"Ralf Weber" <dns@fl1ger.de> Wed, 27 March 2019 23:16 UTC
Return-Path: <dns@fl1ger.de>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC00120094 for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 16:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kzlJpUzw1vH for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 16:16:33 -0700 (PDT)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 941D5120058 for <doh@ietf.org>; Wed, 27 Mar 2019 16:16:33 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id 5D1945F4120F; Thu, 28 Mar 2019 00:16:32 +0100 (CET)
Received: from [172.19.152.18] (dhcp-9104.meeting.ietf.org [31.133.145.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 356765F4039B; Thu, 28 Mar 2019 00:16:28 +0100 (CET)
From: Ralf Weber <dns@fl1ger.de>
To: Eric Rescorla <ekr@rtfm.com>
Cc: DoH WG <doh@ietf.org>
Date: Thu, 28 Mar 2019 00:16:26 +0100
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <1CAFC80D-D72A-417C-B165-F5630D20C7B1@fl1ger.de>
In-Reply-To: <CABcZeBOk5bM+3G2Jd3Lu33Z08gc=AeoZ8UFHzN6AYk4f_hjZ8Q@mail.gmail.com>
References: <CABcZeBOk5bM+3G2Jd3Lu33Z08gc=AeoZ8UFHzN6AYk4f_hjZ8Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/mg-NPWbBITr2J9xCRVs0lU54eTQ>
Subject: Re: [Doh] Mozilla's plans re: DoH
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2019 23:16:38 -0000
Moin! 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 > (https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/).While > 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 based 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 —-- Ralf Weber
- Re: [Doh] Mozilla's plans re: DoH Stephen Farrell
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Stephen Farrell
- Re: [Doh] Mozilla's plans re: DoH N.Leymann
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Vittorio Bertola
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Stephen Farrell
- Re: [Doh] Mozilla's plans re: DoH Ralf Weber
- [Doh] Mozilla's plans re: DoH Eric Rescorla
- Re: [Doh] Mozilla's plans re: DoH Eric Rescorla
- Re: [Doh] Mozilla's plans re: DoH Matthew Pounsett
- Re: [Doh] Mozilla's plans re: DoH Valentin Gosu
- Re: [Doh] Mozilla's plans re: DoH Kevin Borgolte
- Re: [Doh] Mozilla's plans re: DoH Neil Cook
- Re: [Doh] Mozilla's plans re: DoH Tony Finch
- Re: [Doh] Mozilla's plans re: DoH Eric Rescorla
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Stephen Farrell
- Re: [Doh] Mozilla's plans re: DoH Joseph Lorenzo Hall
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Tony Finch
- Re: [Doh] Mozilla's plans re: DoH Vittorio Bertola
- Re: [Doh] Mozilla's plans re: DoH Petr Špaček
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Livingood, Jason
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Vladimír Čunát
- Re: [Doh] Mozilla's plans re: DoH Livingood, Jason
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Eric Rescorla
- Re: [Doh] Mozilla's plans re: DoH Petr Špaček
- Re: [Doh] Mozilla's plans re: DoH Eric Rescorla