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

Paul Vixie <paul@redbarn.org> Tue, 12 March 2019 20:22 UTC

Return-Path: <paul@redbarn.org>
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 D7ED81312EC; Tue, 12 Mar 2019 13:22:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 erGmWWzDBO3r; Tue, 12 Mar 2019 13:22:02 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781391312E3; Tue, 12 Mar 2019 13:22:02 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id ED81C892C6; Tue, 12 Mar 2019 20:22:00 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Cc: Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>
Date: Tue, 12 Mar 2019 20:22:00 +0000
Message-ID: <1914607.BasjITR8KA@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <3457266.o2ixm6i3xM@linux-9daj> <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NoqXxE7XnhSsXl2vGdOwd5B5okw>
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: Tue, 12 Mar 2019 20:22:04 -0000

On Tuesday, 12 March 2019 19:15:16 UTC Ted Hardie wrote:
> ...
> > that's precisely the goal, because very few network operators can
> > preordain the users and apps that will connect through their networks.
> 
> I do not believe this goal is met by what you describe, since an
> application can use a proprietary resolution service in its flows.

rogue flows have their own accounting. my problem isn't with one-off's, 
because traditional security is anomaly-based. DoH, by folding control plane 
data into previously non-anomalous flows, presents a new problem. if CF and G 
and IBM and Cisco decide to offer DoH on the same IP address that they offer 
API's and services i actually do need or want to permit, i'm going to have to 
increase my investment.

this equation, where something is created which is a danger to me, which 
blends in with the crowd of things that are not dangerous to me, is the method 
by which DoH achieves its stated aim, "prevent on-path interference in DNS 
operations." all war is economics. they are increasing my costs, deliberately.

i am on-path and i intend to interfere. at whatever cost that may be. i also 
reserve the right to re-externalize some or all of those new imposed costs.

> Imagine for a moment an application on a smart TV that wants to provide
> content from the closest server which contains that content.  ... Blocking
> destinations for which you have seen no resolution events will work for a
> subset of these cases, but it won't work when the resolution points to a
> common CDN destination.  That approach will, of course, also have a wide
> variety of failure modes when the resolution event data is incomplete for
> timing or other reasons; it will also block all of the flows which MUD
> would handle. 

generally speaking, security policies break down into two categories. allow 
all except some, or deny all except some. which one an operator chooses will 
depend on their goals, budgets, and in particular, the cost of anomaly 
detection. it's the change in cost of anomaly detection, deliberately intended 
by the authors of RFC 8484, which is at the root of some very expensive policy 
choices that the rest of us must now make.

your smart-tv example is not involved in that causalality path. noting also, i 
have a TV which offers the kind of feature you describe, but only if i accept 
its software license. (something to do with GDPR, i suspect.) so i did not 
accept that license, and as a result, i have a disconnected device whose 
flaws, both now known and not yet known, will pose no threats here. my TV, my 
rules.

> > to the extent that monitoring ('dnstap') and controlling (DNS RPZ) dns
> > lookups by connected users and apps is considered a vital local security
> > policy, attempts at such "pass through" must be made to fail.

> Those are security mechanisms, rather than policy, and it may be worth
> teasing apart what the actual desired security policy is.  You may find
> that it is more easily implemented at the routing layer than the resolution
> system in the light of proprietary resolution systems and DoH.

to be clear, the policy is, "allow all, except some". i implement as much of 
this policy as possible at the routing layer, and i do my research on 
proprietary resolution systems to decide whether i can tolerate the risks of 
devices which use such things. (so, no nest thermostats here, the TV's are not 
smart, and the apple home pods are in their not-logged-in state.)

it is the standards nature of DoH that amplifies its imposed costs. i could 
simply outlaw by IP or port# a proprietary or otherwise bespoke protocol. 
(working out with my kids what online games require what permissions, has been 
burdensome on both me and them.) DoH, by _intending to bypass_ network 
operator policy DNS, and my seamlessly hiding in the crowd of TCP/443 
transactions now made indiscernible  by TLS 1.3 and ESNI, is an act of 
economic warfare against all RDNS control plane owners. (deliberately.)

vixie