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

Paul Vixie <paul@redbarn.org> Wed, 13 March 2019 23:06 UTC

Return-Path: <paul@redbarn.org>
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 A60571279B3 for <dnsop@ietfa.amsl.com>; Wed, 13 Mar 2019 16:06:55 -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 arGIkg93fqnJ for <dnsop@ietfa.amsl.com>; Wed, 13 Mar 2019 16:06:53 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15E2127873 for <dnsop@ietf.org>; Wed, 13 Mar 2019 16:06:53 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 09D4C892C6; Wed, 13 Mar 2019 23:06:53 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Kenji Baheux <kenjibaheux@google.com>
Cc: dnsop@ietf.org
Date: Wed, 13 Mar 2019 23:06:51 +0000
Message-ID: <155254290.aeJRSRQI46@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <CADWWn7UVzu7SqP7AC4Vz_7gEM9Z04bPuvjZhpiBM68CphGOC=A@mail.gmail.com>
References: <CADWWn7UZj3oAfqpcpnAenGDpZHatrvQ=97OxAWX8c3881oevhA@mail.gmail.com> <8490858.J4o6DMrmW6@linux-9daj> <CADWWn7UVzu7SqP7AC4Vz_7gEM9Z04bPuvjZhpiBM68CphGOC=A@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1rhnV0IlWMmmIQsDrJVWqGBjI3w>
Subject: Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)
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: 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 <paul@redbarn.org> 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.

vixie