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

Vittorio Bertola <vittorio.bertola@open-xchange.com> Wed, 22 August 2018 08:22 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 32953130E1F for <dnsop@ietfa.amsl.com>; Wed, 22 Aug 2018 01:22:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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] 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 t28AIxy1yJAc for <dnsop@ietfa.amsl.com>; Wed, 22 Aug 2018 01:22:42 -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 59972120049 for <dnsop@ietf.org>; Wed, 22 Aug 2018 01:22:42 -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 521E96A36A; Wed, 22 Aug 2018 10:22:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1534926160; bh=fFJOkbRy2UNpQH37zAGFPRROYq+/1QIvh2Ixr+HfzLI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=92fXcKYUGe2CGfO59cFvEWJMKh8+4x9tDfjcyKhQLxDmLtcP6wvYkyODAD+3rpNi8 dPAkMw2PNlI5rsIWUqDPRZmDvBYI2JBCXSoPUBMQ8A4KWUaBOzGLIcGo8SHQ7RtApB vxJuba4aSmCn9epom9Dwraw/zg+efIC1P4opeqUKTocf3wTYNeLqY1W09x3Yti8b/U QOndXQ8Aj24+yBzT1EL8ePnxz3061pCiC/uhwKPhprOBkuLz7yc5v/jWG/KbRVSCEw gvNNws6iQimQ+OZ3I10m45BCxBVzUnUOrQLCf6X+aInQZrGUYj2gJJR8hEvJw8thzC XUn1xssglIkLg==
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 32A033C1580; Wed, 22 Aug 2018 10:22:40 +0200 (CEST)
Date: Wed, 22 Aug 2018 10:22:39 +0200
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Doug Barton <dougb@dougbarton.us>, dnsop@ietf.org
Message-ID: <42549463.21529.1534926160144@appsuite.open-xchange.com>
In-Reply-To: <1eefcc5a-e1c0-0409-44fa-3e8ed4d471c3@dougbarton.us>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@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> <63b113eb-9372-b622-b346-5d926f0b5d9a@nic.cz> <m1fs8g9-0000GpC@stereo.hq.phicoh.net> <20bfadaf-05bf-d564-9c90-bd1464b23328@nic.cz> <1eefcc5a-e1c0-0409-44fa-3e8ed4d471c3@dougbarton.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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/oki3d032QcYR35Bh5nk3wFoLB7Y>
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: Wed, 22 Aug 2018 08:22:44 -0000

> Il 22 agosto 2018 alle 7.18 Doug Barton <dougb@dougbarton.us> ha scritto:
> On 08/21/2018 09:19 AM, Vladimír Čunát wrote:
> > Ehm, we somehow forgot that this thread is supposed to be about DHCP, so
> > that's only the "uninteresting" case where you do trust the ISP and want
> > to use their DNS over a secure channel:-D
> 
> This perspective that users "trust" their network environment is deeply 
> flawed. Users don't understand how any of this stuff works, and we 
> should not be making any decisions with that as a premise.

But we should also not make the premise that the user does not trust the network environment. It really depends on the situation.

Also, there are cases in which the user perhaps does not trust his network, but his network has the right to enforce policies on the user: think at the employees on a corporate network. We should be making this enforcement easier, not harder - for example, adding ways for the network operator to communicate to DoH operators that certain restrictions have to be put in place for the users of its network.

Moreover, even if the user does not trust his network and has the right to do something about this, you cannot also assume that he trusts his application maker or his destination website operator more than he trusts his network. Actually, if you define trust in terms of expectations, until now the users that understand what we are talking about expect their network operator to provide the resolver, not the application maker.

The real problem here is that you cannot establish a trust model that is always valid, and the trust model that applies to a situation can be opposite to the model applying to another one, without any automatable way to distinguish among the two.

This is also what makes this issue so thorny. You can decide that, in the end, the only way to get out of this is to entrust the user with the choice of who to trust, though, as you say, many users will not be able to make an informed choice. Or you can entrust the network operator or the DoH server operator: it is more likely to make competent choices, but in some cases might not make them in the user's interest, though in some cases it also has the right, or even the legal duty, to make choices that users dislike. All in all, I see no easy way to find a model and a policy that work in all cases.

Regards,
-- 

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