Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

"Ralf Weber" <dns@fl1ger.de> Sat, 16 March 2019 13:22 UTC

Return-Path: <dns@fl1ger.de>
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 4397B1200B3; Sat, 16 Mar 2019 06:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 XEleXjjqwqy1; Sat, 16 Mar 2019 06:22:43 -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 8784E1277D7; Sat, 16 Mar 2019 06:22:43 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id 93EF75F42201; Sat, 16 Mar 2019 14:22:40 +0100 (CET)
Received: from [172.19.40.118] (p4FF53E78.dip0.t-ipconnect.de [79.245.62.120]) (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 94FC05F40723; Sat, 16 Mar 2019 14:22:39 +0100 (CET)
From: "Ralf Weber" <dns@fl1ger.de>
To: "Ted Hardie" <ted.ietf@gmail.com>
Cc: "Paul Vixie" <paul@redbarn.org>, dnsop <dnsop@ietf.org>, "DoH WG" <doh@ietf.org>
Date: Sat, 16 Mar 2019 14:22:37 +0100
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <5F768C24-4ECF-4369-9D51-B90C4426409B@fl1ger.de>
In-Reply-To: <CA+9kkMCgmzjbPM+DTUYuS3OsT+wOCmsyaGPg6fPu=w-ibL=NrA@mail.gmail.com>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <1900056.F7IrilhNgi@linux-9daj> <CA+9kkMCgmzjbPM+DTUYuS3OsT+wOCmsyaGPg6fPu=w-ibL=NrA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4ekCQrkcBZlttCQtwtK1q3p397E>
Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 16 Mar 2019 13:22:46 -0000

Moin!

On 15 Mar 2019, at 19:36, Ted Hardie wrote:
> As was pointed out in many groups, trusting the local infrastructure is
> extremely problematic in nomadic cases as the local infrastructure can
> often be infected, ill-maintained. or hostile by design.  Given the
> extremely high percentage of users who are now on the Internet by mobile
> devices which roam and opportunistically use WiFi, ignoring this reality
> would not make sense.  So we rely on configuration of end devices and
> applications, with the belief that the user has some choice there in both
> how the end device is configured and in what applications are supported.
> That's a trade-off, and not a simple one to make, both because it is very
> difficult for end users to make that assessment and because there's a high
> reliance on sensible defaults.  But that choice is an engineering
> trade-off, not an act of war against you or any other network operator.
You can not get on a network with at least trusting some of its
infrastructure, be it SLAAC or DHCP (which BTW both carry information
for DNS resolving). The question is where you draw the line and IMHO
DNS or name resolution is a basic network function and not an application
setting.

> If the user configures your DNS service they get it, and their trust in
> your operations to provide appropriate answers is thereby matched to your
> desire to see the requests.
Yes and this capability existed in operating systems for some time and
was used by some people. It didn’t cause any concern as if a network for
some reason didn’t want to allow user to use external resolving (which is
the case in pretty much every enterprise network) they could simply block
it. This is not so easy with DoH.

> For a very large number of enterprise
> networks, the result is that devices are permitted on the network only when
> under some form of device management, with the proxies, configuration,  and
> limitations that implies.  To protect itself, the enterprise insists on a
> prior relationship with known terms, instantiated by the configuration of
> device management.  There are lighter forms of configuration that do the
> same thing to lesser degrees, but they each presume that a trusted edge
> network operator has a relationship to the users that can effect
> configuration.
This never was fully true and with more and more bring your on device
requiring this will get harder, so network providers (ISP, enterprises,
my home network ;-) have to have tools to apply their network rules,
or if people don’t want to play by the rules block them.

So long
-Ralf
—--
Ralf Weber