Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Jim Reid <jim@rfc1035.com> Tue, 21 August 2018 18:32 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662D7130E32 for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 11:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CRt09vOjZryY for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 11:32:25 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C500130E25 for <dnsop@ietf.org>; Tue, 21 Aug 2018 11:32:25 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id C7DAC2420FDE; Tue, 21 Aug 2018 18:32:21 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
X-Priority: 3
In-Reply-To: <1792164436.19856.1534865022391@appsuite.open-xchange.com>
Date: Tue, 21 Aug 2018 19:32:20 +0100
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7311CF3-D1F6-431C-8AEE-D1464417EB6B@rfc1035.com>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <CAC=TB11tG4o0dkavXGb20=DGBCrmVoRP60bpzsvq5=Q0zFjhDg@mail.gmail.com> <CAPt1N1kj7Y0dPLeDk=PMqQEpAd-Mvds6VLT8XUC1BYOfdyUbJA@mail.gmail.com> <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <5B78BFB9.40103@redbarn.org> <47508D79-0D49-4F31-9BA6-6DC80C38F1DE@cable.comcast.com> <ad1f6dff-ebcc-97a9-6f4b-1ed683827cc7@dougbarton.us> <1313743534.13562.1534765718802@appsuite.open-xchange.com> <9AFE57A7-1D27-4F86-9013-E3C63E63C582@hopcount.ca> <5B7AE322.3020201@redbarn.org> <CAPt1N1m-Xd-7rvgmk8GOsx34=1hsu76nmTgW-8krC3JF7i57KQ@mail.gmail.com> <265867956.15518.1534783313366@appsuite.open-xchange.com> <CAPt1N1myrdOywur35rXRab2QCrhFiJ0vS4wnT_Pof0epdOPz7A@mail.gmail.com> <471139805.18285.1534847636363@appsuite.open-xchange.com> <m1fs7wB-0000GtC@stereo.hq.phicoh.net> <1792164436.19856.1534865022391@appsuite.open-xchange.com>
To: Vittorio Bertola <vittorio.bertola@open-xchange.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jTkhOJVxMys9OKsRW-v_BX9tiQE>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2018 18:32:27 -0000

On 21 Aug 2018, at 16:23, Vittorio Bertola <vittorio.bertola@open-xchange.com> wrote:
> 
> And I have yet to see a statement from the DoH community that Mozilla's idea of making DoH the default and disregarding whatever resolver is being configured in the system via DHCP is not a good one.

Why would/should the DoH community -- whatever that is -- make such a statement? In some cases, it will be better to use the current network’s resolving DNS servers. In others it won’t. For some definition of “better”. The use or non-use of DoH is somewhat orthogonal to those underlying considerations. 

Deciding what’s “good” or “bad" gets very messy very quickly. For instance I might decide to trust $coffeeshop’s resolver in my home town (say) but not at a branch of $coffeeshop that's behind the Great Firewall of China. Or $coffeeshop’s outlet in the foyer of my employer’s building.

> Actually, during the discussions in Montreal there were people talking about centralized DNS operators paying the browser makers to get their DNS traffic, and then monetizing it to get back the money. How can this be presented as "more privacy" is baffling.

If this happens, it can be worked around. Almost nobody is going to be forced to use privacy-unfriendly browsers or resolvers at gunpoint. Besides, providers offering “even more privacy” will emerge if this centralisation/monetisation thing turns out to be a problem. Having low barriers to entry is one of the nice things about the Internet. Well OK, it’s a nice thing some of the time. :-)