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

Jared Mauch <> Wed, 20 March 2019 01:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42E0E130DC2; Tue, 19 Mar 2019 18:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EPQFDKyUYnpf; Tue, 19 Mar 2019 18:24:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAFA6128DFF; Tue, 19 Mar 2019 18:24:36 -0700 (PDT)
Received: from [IPv6:2603:3015:3606:cbe1:cd14:2c86:15f5:ed4e] (unknown [IPv6:2603:3015:3606:cbe1:cd14:2c86:15f5:ed4e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1EFF0540DB8; Tue, 19 Mar 2019 21:24:34 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jared Mauch <>
In-Reply-To: <>
Date: Tue, 19 Mar 2019 21:24:33 -0400
Cc: paul vixie <>, dnsop <>, DoH WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <1914607.BasjITR8KA@linux-9daj> <> <1900056.F7IrilhNgi@linux-9daj> <>
To: Ted Hardie <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Mar 2019 01:24:38 -0000

> On Mar 15, 2019, at 2:36 PM, Ted Hardie <> wrote:
> All of the work on encrypted DNS presumes that there is one or more parties who wishes to observe the flow of traffic to DNS resolvers for the purposes of surveillance.  The conclusion of the IETF after IETF 88 was that there was a class of that, pervasive public surveillance, that was so damaging to the trust of the users in the Internet that it amounted to an attack on the value of the Internet as a whole.  The plenary where that was discussed is online here: IETF 88 Technical Plenary: Hardening The Internet - YouTube . In a path with multiple links, in other words, we have a condition where we believe there is likely to be an attacker on one or more of those links that would like to see this data and to use it for purposes not approved by the user or the operator of the service to which the user is directing her flows (or any of the network operators through which the flow passes).   
> The response to that has been first to encrypt the flows which carry the user data.  That's not an effort championed not only by the IETF or the IAB; see the US Government's HTTPS Only standard for one example of the many other efforts going on to make that the case.  In addition to that primary effort, there have been efforts to reduce the amount of metadata about the flows.  Some of that has been in updating transport protocols (e.g. QUIC, TCPINC) to reduce their disclosure of state.  Some of it has been in reducing the data revealed by the handshake (e.g. the updates in TLS 1.3 and eSNI).  And some of it has been to reduce the data disclosed across those links by the use of the DNS.  That's the point of DNS over TLS and DNS over DTLS; it's also the point of DNS over HTTPS: to protect the data in those flows from a known, pervasive attacker. 
> You would like your use of similar surveillance techniques to be differentiated from their use by that set of attackers.  The IETF cannot do that on moral grounds, much as we might like you and appreciate your desire to protect your network and your children. We need technical mechanisms.  If you review the discussion to date, you'll see a number of such mechanisms proposed.  They fall into two broad classes: trusting the local network infrastructure and trusting the local configuration.  

Once you make all traffic look the same, expect it to be treated the same as possibly malicious by network operators.  

Do you know why software has options like avoid-v4-udp-ports as a config directive?  Expect that to happen regardless of where you move the transport to.

I’m writing this from my own machine that I own, purchased and paid for with my own $$.  If you’re writing from a corporate owned machine, or reading on a corporate owned machine they likely have their own rules for them.  I believe in the open internet, but I also don’t believe in the absolutes people see this in.  You aren’t entitled to all communication in the world.  The IETF can try to carve out a moral high ground that you are referring to.  It may be sound footing, but if you’re in a place where a DNS query for is problematic, one of the solutions is to NOT look up  It may not be “right” in your mind, but it is a way to prevent being jailed or otherwise which we may both morally agree is the wrong outcome but those other locations that made bad may not care and no writing to/in an IETF WG will change that a single bit.  That change lives outside the IETF WG process.

- Jared