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

Kenji Baheux <> Wed, 13 March 2019 10:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F7A5130EBF for <>; Wed, 13 Mar 2019 03:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lf3LQ8PHZuvs for <>; Wed, 13 Mar 2019 03:21:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 001E0130EE4 for <>; Wed, 13 Mar 2019 03:21:12 -0700 (PDT)
Received: by with SMTP id z20so1011097ljj.10 for <>; Wed, 13 Mar 2019 03:21:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0ewwpOk+bIKalxVQgAb4brn1CK9UUUCa53AYn2K4x5E=; b=aO28zZnx3t2u/DPPVklzRjJ40iIr550m0qKChpk2c1CQRaG0idZ2pdHSYLJBAgB/nA 2wcCoAk6ItDhQge4kXyovW0u+T5a6ZfFRHDxv0rOQ2Ur60SjFm3kilwNAPgbpEsAAShF 3rCjvpdIoQeMMAwc/fjg9JyNGip6zdXEzmwNxlXRBiHH8ZEZh2+hq7EQR+NG7Uvsvzpj Dwc0L2lOgddGm9dSs+LkW+E/gClViOFKMcruaXwjnmYDdPbjnoywPTOmzfeHdE/ZcB+G LNkODtF78agwOL8mMlPWBpCSYuTVMiPZKmiYwqt/rkKLJBqIG9uIsGrxIuEvgu+q38Q3 miDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0ewwpOk+bIKalxVQgAb4brn1CK9UUUCa53AYn2K4x5E=; b=exbmZOjlI8ceJS8nKyoAFMSztTTacgEdopW4CTRZzjjBvcgRJAEFfOFudKI2vd++nX Z8Wj/6hDrN4P7ar2DwXBCKWwQ8BFNujkk+LXBRxo9aSE1wSJ1Oemueu+0D1YL9VITreg Qu1qt71QeATBRgu5IGke757xjbRDujftBF5OZuB5DpaDnexeeGL26ruXmBJ6XyNSc2eT 8rpDRy75g+yfgMebbtZkXv2OR04CpRloEMVfUM7si1TmQsvceE3ZiNLLXJMYvWMtivS6 qNYJIXYPPvLwyipje8lpiDoHOwDPUGpK977OkPhfwMaRYU1y9ACx7OZgoKTxsDmQllG1 9GVw==
X-Gm-Message-State: APjAAAUH7VbjwrsCQo451MCVexYo28hhQP7pW/kM/0Ohin01EKk+1B8x +6JafgBAjRLuStHxM4MK2cxhyfJwJxOFeQVq32LImMu4qd3eZQ==
X-Google-Smtp-Source: APXvYqwaH/Vjzubrwwr5I6Wixh8Uc7DjAFEB0BEQTwMy/hrj7wIgs+wGObUXBZjTzsTp4K8To5Esvjgxu4RVmdAKoGE=
X-Received: by 2002:a2e:9355:: with SMTP id m21mr22627948ljh.172.1552472470855; Wed, 13 Mar 2019 03:21:10 -0700 (PDT)
MIME-Version: 1.0
References: <> <8490858.J4o6DMrmW6@linux-9daj>
In-Reply-To: <8490858.J4o6DMrmW6@linux-9daj>
From: Kenji Baheux <>
Date: Wed, 13 Mar 2019 19:20:58 +0900
Message-ID: <>
To: Paul Vixie <>
Content-Type: multipart/alternative; boundary="000000000000268d0c0583f72a76"
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 10:21:17 -0000

On Wed, Mar 13, 2019 at 4:41 PM Paul Vixie <> wrote:

> On Wednesday, 13 March 2019 02:33:14 UTC Kenji Baheux wrote:
> > *(Sincere apologies about the multi-posting but the discussion seems to
> be
> > happening in different places...)*
> >
> >
> > Hi,
> >
> > I'm involved with Chrome's DoH efforts.
> >
> > ...
> >
> > PS: I won't be able to join IETF 104 to discuss this face to face, but I
> > will see if someone from our side can represent us.
> thank you for this information. 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'm also not sure why / how a browser could prevent these type of issues
from happening by merely shipping DoT on top of DoH.

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?

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?

> vixie

Product Manager - Chrome
Google Japan