Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

Paul Vixie <> Mon, 11 March 2019 05:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 043A4130F32; Sun, 10 Mar 2019 22:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5WSArU3Zfkg9; Sun, 10 Mar 2019 22:25:00 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DFEE130F2B; Sun, 10 Mar 2019 22:25:00 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:c469:941:d0ef:306d] (unknown [IPv6:2001:559:8000:c9:c469:941:d0ef:306d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id BD4E8892C6; Mon, 11 Mar 2019 05:24:59 +0000 (UTC)
To: Christian Huitema <>
Cc: nalini elkins <>,, Vittorio Bertola <>,,, "Ackermann, Michael" <>, Stephen Farrell <>
References: <> <> <> <> <> <>
From: Paul Vixie <>
Message-ID: <>
Date: Sun, 10 Mar 2019 22:24:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/6.1.11
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Mar 2019 05:25:02 -0000

Christian Huitema wrote on 2019-03-10 21:14:
> There are a bunch of conflicting requirements here, and it would be good
> to tease out the contradictions. Consider the following cases:
> 1) I am using my phone, and using application-X.
> 2) I am at home, using application-X on my home computer.
> 3) I am using Wi-Fi in a hotel, and using application-X.
> 4) I am using my work laptop on the enterprise network, and using
> application-X
> 5) I am using my work laptop in a hotel, and using application-X
> 6) I am using my work laptop on the network of a customer, and using
> application-X.

this distinction is not useful.

there are two cases.

a user or app trusts its network.

or not.

in the first case, you'll use an RDNS service which is in the set 
(allowed (preferred)). that is, you'll use the server you desire most 
out of the set that your network operator allows you to reach.

in the second case, you'll use a VPN, for all of your traffic, not just 
for DNS, because if you hide your DNS but not the connections which 
result from such hiding, it will add no measurable privacy.

> Today, plenty of people claim the right to control how I use the DNS: my
> phone carrier, my ISP at home, the company that got the contract to
> manage the hotel's Wi-Fi, the IT manager for my company's laptop, the IT
> manager for the company that I am visiting. Out of those, there is just
> one scenario for which the claim has some legitimacy: if the company
> pays for my laptop and own the laptop, yes of course it has a legitimate
> claim to control how I am using it. Otherwise, I, the user, get to
> decide. If I like the application's setting better than the network's
> default, then of course I expect those settings to stick.

this distinction is also false.

if you are using my network, then it makes no difference which of us 
bought you that laptop. you will use the RDNS i allow you to use. RDNS 
is part of the control plane, and i use it for both monitoring and 
control. sometimes that's so that i can see malware beacon to its C&C. 
sometimes that's so that i can institute parental controls.

if you don't like my rules, you should vote with your feet, and not 
visit me. because that is the only choice you will have. (yes, i will be 
part of a major new project to identify and block all DoH services, so 
that behavioural security policies can still work, because you may have 
noticed that the internet has never become MORE secure from new tech, 
but it occasionally becomes LESS secure more slowly because of policy.)

quoting again the salient passage of RFC 8484's self-damning introduction:

> ... Two primary use cases were considered during this protocol's 
> development. These use cases are preventing on-path devices from 
> interfering with DNS operations, ...

let me give you advance notice: "i aim to misbehave."[1] that is, _i am 
on-path, and i intend to interfere._ why on earth the IETF decided to 
equate dissidents (of whom there are tens of thousands, all of which 
need full VPN's not just DoH for actual safety) with bots (of which 
there are tens of millions), and set up a war between end users and 
network operators, i will never understand, or try to. now, we fight.

P Vixie