Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
"John Todd" <jtodd@quad9.net> Fri, 15 March 2019 21:33 UTC
Return-Path: <jtodd@quad9.net>
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 D7E891279E6 for <dnsop@ietfa.amsl.com>; Fri, 15 Mar 2019 14:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 91OCygSMS2Pg for <dnsop@ietfa.amsl.com>; Fri, 15 Mar 2019 14:33:02 -0700 (PDT)
Received: from mail1.quad9.net (zmail1.sjc.rrdns.pch.net [216.21.3.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6EE0126F72 for <dnsop@ietf.org>; Fri, 15 Mar 2019 14:33:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail1.quad9.net (Postfix) with ESMTP id 8181FC1482A2; Fri, 15 Mar 2019 21:33:01 +0000 (UTC)
Received: from mail1.quad9.net ([127.0.0.1]) by localhost (mail1.quad9.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ep0EkR_ICqo6; Fri, 15 Mar 2019 21:33:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail1.quad9.net (Postfix) with ESMTP id 8C911C1306F8; Fri, 15 Mar 2019 21:33:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at quad9.com
Received: from mail1.quad9.net ([127.0.0.1]) by localhost (mail1.quad9.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XfFZVmsIsu_i; Fri, 15 Mar 2019 21:33:00 +0000 (UTC)
Received: from [172.16.181.1] (unknown [69.5.96.145]) by mail1.quad9.net (Postfix) with ESMTPSA id 14921C1482A2; Fri, 15 Mar 2019 21:33:00 +0000 (UTC)
From: John Todd <jtodd@quad9.net>
To: Raymond Burkholder <ray@oneunified.net>
Cc: Ted Hardie <ted.ietf@gmail.com>, Paul Vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>
Date: Fri, 15 Mar 2019 14:34:37 -0700
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <EF147921-82ED-4EB6-8FEA-51E2646DF986@quad9.net>
In-Reply-To: <b6bb26c2-9e25-ed54-79b9-6936ef249de5@oneunified.net>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <5456b9d9-844f-f410-3935-2b2d3ae22745@redbarn.org> <CA+9kkMDo54N=DoL1HAQoMYSe1jrexXXrA3ZXkkve0CJ2-bvd4Q@mail.gmail.com> <3457266.o2ixm6i3xM@linux-9daj> <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com> <b6bb26c2-9e25-ed54-79b9-6936ef249de5@oneunified.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VqzetlGrQS1d6GebUldV3BlNJKk>
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: Fri, 15 Mar 2019 22:25:09 -0000
On 12 Mar 2019, at 20:05, Raymond Burkholder wrote: > On 2019-03-12 1:15 p.m., 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. > > but there are more than just network operators. There are security > people at all levels of organizations who are extremely interested and > who are empowered to manage/monitor what is happening inside a > network. DoH removes much of this power. I'm not sure if that is a > 'good thing'. > >> I do not believe this goal is met by what you describe, since an >> application can use a proprietary resolution service in its flows. >> Imagine for a moment an application on a smart TV that wants to >> provide content from the closest server which contains that >> content. It can use a redirect from the original server when a new, >> closer server comes online (or when a different server has that >> content), and it can provide the mapping between that server and one >> or more addresses for that server with the redirect, in whatever >> format its individual cache can store. All of this can take place >> within its confidential channel, using whatever proprietary format >> they find convenient. In that case, the local network will see new >> flows to the new servers without having observed the resolution >> event. 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. > > I think that is to be expected: when a network operator (enterprise, > home, organization) is dynamically adjusting ip based rule-sets based > upon what meta-data can be derived from flow inspection. If a > proprietary resolution service is used, then it is expected that 'by > default blocks' will be performed if the traffic protection engine is > not appraised of change. > > If DoH is implemented, then traffic, whether it be lookup, or > otherwise, in a 'default drop' scenario is just going to have to be, > well, 'default dropped'. Brute force I guess is the protection > mechanism. > > So, I think, then, this begs the question, how can the needs/desires > of those in charge of security be balanced with the needs/desires of > those who desiring to bypass inspection? > > I guess the maxim 'my network, my rules' holds. But what DoH will > cause is an even increasing tightening of network rules. With current > passive DNS pass-through, DNSEC and such can remain unmolested, but at > least follow-on flows can be identified for forensic or security or > policy purposes. With DoH, this correlation can not be performed, and > thus, by default, a user's ability will be more restricted in order to > prevent unknown unknowns from happening. > > The only way around this, for a security operator's perspective, will > be certificate insertion so that proxying can be performed. And we are > back to what we currently have anyway. > > Would a compromise be that, if someone requires personal security, the > standard fall back would be to use a VPN? > >> >> 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. > > You've mentioned that 'security' is separate from 'policy' and then > mention 'security policy'. And I implicitly agree with the latter, > security and policy go hand in hand, and are difficult to separate. > > Handling at the routing layer is not possible. Handling at the > interrogation/interception/transparent-evaluation intelligence layers > is where it begins. This information then feeds the > interior/perimeter protection layers. The policies implement the > security. > > If the interrogation/interception/transparent-evaluation layers are > unable to identify key interactions, then security is unable to be > performed. > > Raymond [removing doh@ietf.org from cc: list, as this message is on operational implementation only] Agreed with what Raymond has said above, and most of what Paul Vixie has said previously on this topic. We see no significant improvement that DoH brings to security or privacy that DoT does not already offer, and also believe DOH’s stated goal of obscurity via port and origin source IP conjoining is dangerous and ultimately misguided in respect to the goals of increasing privacy and permitting content access. Keep control and content channels separate, even if it allows blocking to be easily effective. If there is the thought that clever obfuscation will prevent blocking, then that is vastly underestimating the legal, administrative, and commercial force which will be applied to prevent the DoH model one widely adopted, and then the subsequent privacy wreckage that force will cause. We expect to see the “block everything and force national/enterprise certs” model expanding in the near future, which we believe to be ++bad. DoH throws gasoline on that fire if content and DNS are indistinguishable and commonly bundled. Maybe always-proxied connections are an inevitable condition for some large portion of Internet users, but we would prefer not to see the angle of the growth slope increase so quickly as it might if DoH is implemented in ways that aggressively and intentionally oppose local network policy enforcement. Quad9 supports DoH currently, but recommends DoT. We are not opposed to DoH as a protocol, but we fear the political results of deployment models by others which take Internet content as hostage in front of DoH services. The optimistic hope by DNS operators that websites can be used as a “shield” against blocking will end badly for the people who need security the most, since those users are typically on networks or within nation-states which have the highest incentives to react strongly and in a privacy-negative way to perceived or real policy circumvention at scale. Mainland China’s example of network filtering is a template to control-oriented operators as one such response result. We will not serve non-Quad9 HTTPS content on the same IP addresses as our public resolvers. We will keep the number of DNS-serving endpoints we operate to a relatively small list of anycast netblocks that can be identified as being “DNS-only” in nature. We hope that organizations that offer content and open DNS recursive resolution will not try to combine DNS and HTTPS in a way that is impossible to “cheaply” block by local network operators. Otherwise we see a condition where those operators in the hopes of regaining control will choose to block/proxy all traffic to all destinations, and not just block DNS. If that type of deny-all (or “intercept-all”) filter is implemented as it has been in existing examples then this appears to us to be a worse outcome that we would want to try to avoid. JT -- John Todd - jtodd@quad9.net - +1-415-831-3123 Executive Director - Quad9 Recursive Resolver
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Warren Kumari
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephane Bortzmeyer
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephane Bortzmeyer
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ask Bjørn Hansen
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Michael Sinatra
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Raymond Burkholder
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Raymond Burkholder
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Winfield, Alister
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator John Todd
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ralf Weber
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator John Levine
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Lemon
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Christian Huitema
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Hardie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Winfield, Alister
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Christian Huitema
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator nalini elkins
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Joe Abley
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jacques Latour
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Adam Roach
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator 神明達哉
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jacques Latour
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jacques Latour
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Brian Dickson
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator John Levine
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jim Reid
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Wes Hardaker
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Christian Huitema
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Vittorio Bertola
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eric Rescorla
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ray Bellis
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Winfield, Alister
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator sthaug
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Joe Abley
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Winfield, Alister
- Re: [DNSOP] [EXTERNAL] Re: [Doh] New I-D: draft-r… Joe Abley
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Eliot Lear
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Ted Lemon
- Re: [DNSOP] [Doh] (dhc discovery) New I-D: draft-… Normen B. Kowalewski
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Bill Woodcock
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Livingood, Jason
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Joe Abley
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Puneet Sood
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Stephen Farrell
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Richard Bennett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Richard Bennett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Wes Hardaker
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Jared Mauch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Matthew Pounsett
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Paul Vixie
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Vittorio Bertola
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Paul Wouters
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Olli Vanhoja
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Daniel Stenberg
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Mark Andrews
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ian Swett
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… sthaug
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Valentin Gosu
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ray Bellis
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Eliot Lear
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Stephen Farrell
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Eliot Lear
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Patrick McManus
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Brian Dickson
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ted Lemon
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ray Bellis
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Tony Finch
- Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator Puneet Sood
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Tony Finch
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ted Lemon
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Tony Finch
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Ted Lemon
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… Paul Vixie
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… tirumal reddy
- Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-r… tirumal reddy