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

Vittorio Bertola <vittorio.bertola@open-xchange.com> Tue, 21 August 2018 15:23 UTC

Return-Path: <vittorio.bertola@open-xchange.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 8140B130DDB for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 08:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
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 TmJtkFMkExqY for <dnsop@ietfa.amsl.com>; Tue, 21 Aug 2018 08:23:44 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C5A130F25 for <dnsop@ietf.org>; Tue, 21 Aug 2018 08:23:44 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 931C26A377; Tue, 21 Aug 2018 17:23:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1534865022; bh=MeJnyM2r4F+GQOYVPuQtZIcK12WbeQbYJT9uaosXiM8=; h=Date:From:To:In-Reply-To:References:Subject:From; b=qZ+Y6JcfNslo4bMFrqH/JLU9Xn3y+FtgbTAS76XRicEZjJfCkl6/dssGnchOfPDkr /nBm2FV7BgjVYjzz5ibeq011q6ZLfMkQoQ7IWzeXFWjFZdeGxiwYV8nyQtMXwN2OM9 uim23Wmq3BjILgzBVFexpHcjKhVOWvegKRVPi65FLqmbztcroNPGtk0MstwL8xFJlz 5xdTUYn2lmSmEJVkWlI5bbXoBqfLYp8ovt25FRRfVl24aDCwi1s4TF4gFpHT+ZGt9q w+TDCOJs0UQXcWkxbYIAiMjx0mmyhcQ3rRaVKb85l//RGgGWpyCaS2QxfTB6HzsV2X rtnBYF22XJH1A==
Received: from null (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 703603C095E; Tue, 21 Aug 2018 17:23:42 +0200 (CEST)
Date: Tue, 21 Aug 2018 17:23:42 +0200 (CEST)
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>, dnsop@ietf.org
Message-ID: <1792164436.19856.1534865022391@appsuite.open-xchange.com>
In-Reply-To: <m1fs7wB-0000GtC@stereo.hq.phicoh.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.0-Rev11
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/--_A2oYaiPLZhCJWmdczMQVx8bc>
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 15:23:49 -0000

> Il 21 agosto 2018 alle 16.47 Philip Homburg <pch-dnsop-3@u-1.phicoh.com> ha scritto:
> 
> 
> > If I got it well, what you are trying to bypass is your ISP's
> > security filter that prevents you from connecting to malware or to
> > illegal content (e.g. intellectual property violations and the
> > likes). 
> 
> As a user, I think there is little reason to trust an ISP.
> 
> If you take a mobile device, do you trust every hotel, bar, etc. where you
> may connect to the wifi? Are they all competent? Are you sure none of them will
> violate your privacy?

Sure, roaming at hotels and cafes is a good use case for encrypted DNS, though for many people it is not the typical Internet access situation (not everyone travels to conferences all the time). Most people here in Europe either access the Internet at home or at work through DSL or fiber, or access it on their mobile phone using the mobile operator's data network. In fact, roaming wi-fi connections, while still relevant (especially for international tourists), are getting less and less used, since everyone now gets several gigabytes of EU-wide mobile data per month included with their base mobile fee.

Still, I'm all in favour of encrypting and authenticating DNS connections when you are in that situation. However, this should not be done in a way that breaks many other use cases.

> If you have only a few ISPs to chose from, do you trust that ISP?

How many browsers can I choose from? Definitely many less than the possible ISPs, and not a single one from the jurisdiction I live in.
 
> There are many ISPs that try to do the right thing for their customers.
> There are quite a few ISPs that have court orders to do things that go against the interests of their customers.

Yes, but that's the law. I still don't get how is it possible that the IETF is releasing a technology openly designed to allow people to break the law. In my part of the world, this is ethically unacceptable, and possibly also illegal.

> And the are quite a few ISPs that are positively evil.
> 
> You need to have options in case you can't trust the ISP.

Why would you ever use an ISP that you don't trust and that is positively evil?

> > build a sort of "nuclear bomb" protocol
> > that, if widely adopted, will destroy most of the existing practices
> > in the DNS "ecosystem" 
> 
> There is no reason why DoH has to be deployed as a 'nuclear bomb'.

Ok, this is the real issue. There is no reason why, but this is how it is being deployed, starting with Mozilla. 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. 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.

Perhaps what we are missing is just a set of policy guidelines on how DoH should be deployed by operators and application developers, though I do not know how you could then enforce them.

> Hosts can still default to using the resolvers offered by DHCP only switching
> to public resolvers when directed by the user.

No, they can't, if the application defaults to its own resolvers, possibly not even letting the user choose different resolvers unless they click into three-level-deep configuration menus.

> The big difference is that when the user does decide to bypass the ISP's
> resolvers, there will be no way for the ISP to interfere.

Good luck explaining that to several hundred governments that rely on mandatory DNS filters to enforce gambling, hate speech and pornography regulation.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy