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