Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)

Paul Vixie <> Wed, 13 March 2019 23:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A60571279B3 for <>; Wed, 13 Mar 2019 16:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id arGIkg93fqnJ for <>; Wed, 13 Mar 2019 16:06:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A15E2127873 for <>; Wed, 13 Mar 2019 16:06:53 -0700 (PDT)
Received: from linux-9daj.localnet ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 09D4C892C6; Wed, 13 Mar 2019 23:06:53 +0000 (UTC)
From: Paul Vixie <>
To: Kenji Baheux <>
Date: Wed, 13 Mar 2019 23:06:51 +0000
Message-ID: <155254290.aeJRSRQI46@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <>
References: <> <8490858.J4o6DMrmW6@linux-9daj> <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <>
Subject: Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)
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: Wed, 13 Mar 2019 23:06:56 -0000

On Wednesday, 13 March 2019 10:20:58 UTC Kenji Baheux wrote:
> On Wed, Mar 13, 2019 at 4:41 PM Paul Vixie <> wrote:
> > ... can i request that you offer DoT as a
> > solution, not just DoH? they offer the same capabilities of secrecy and
> > authenticity, but DoT can be cheaply disabled by the network operator,
> > whereas
> > a malicious user or app using DoH will be very expensive to detect or
> > prevent
> > at the network level.
> I'm not sure I understand in which scenario this would provide user
> benefits over DoH.

i plan (speaking as a network operator) to deploy and use DoT, but not DoH. i 
would like my users to have the benefits DoT offers, since it is an 
improvement over plain text in some parts of the topology here.

> I'm also not sure why / how a browser could prevent these type of issues
> from happening by merely shipping DoT on top of DoH.

i intend to cooperate with all network operators. when i travel, if DoT fails, 
i will know that the network operator does not want me to have privacy. i can 
then make an informed choice about whether to violate that policy, or not.

DoH deliberately obfuscates that condition, which is dangerous to me.

> If there is a malicious user or app on a network that someone is trying to
> protect, isn't the very existence of these players the actual issue that
> needs to be addressed?

i'll be happy to discuss the ways in which controlled RDNS helps detect such 
malicious activity, as a valuable contribution to addressing that activity. 
but i think i err'd in mentioning it here, since as you say, it's not the 
browser maker's problem.

> On the other hand, for the set of use cases that I do understand, the
> ability for a network operator (not the admin) to cheaply disable DoT, and
> as a result downgrading DNS to vanilla queries, appears to be a significant
> downside for end-users. Taken to an extreme, it seems to imply that
> shipping DoT is effectively the same as not shipping it.
> What am I missing?

encryption and authenticity of DNS transactions has value even when the user 
and the network operator intend to cooperate. i'm not going to deploy DoH, 
however, nor use it when i travel. DoT, by working only when the user and the 
network operator are in cooperation, is a valuable technology for my needs as 
both an end user and a network operator.

thank you very much for your time.