Re: [Doh] WG Review: DNS Over HTTPS (doh)

Adam Roach <> Fri, 15 September 2017 19:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3BF8013422C; Fri, 15 Sep 2017 12:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id idbqbpooAoDp; Fri, 15 Sep 2017 12:00:29 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68C74134213; Fri, 15 Sep 2017 12:00:26 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id v8FJ0NeM066450 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Sep 2017 14:00:23 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be
To: Paul Hoffman <>, Ted Hardie <>
Cc:, IETF <>
References: <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Fri, 15 Sep 2017 14:00:23 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Sep 2017 19:00:30 -0000

On 9/15/17 1:24 PM, Paul Hoffman wrote:
> Yes, please. The charter should say "HTTP/2 over TLS". There is no 
> reason for current browsers adding this feature to add it using an 
> obsolete protocol.

I think you're assuming a tighter coupling between layers than actually 

In particular -- since you're talking about browsers -- it would easy to 
implement the current draft entirely in content JavaScript. In doing so, 
it would be impossible for the implementation to prevent its use over 
HTTP/1.1 (or QUIC): aside from some proprietary browser-specific APIs, 
there's no way for such an implementation to even tell what version of 
HTTP is in use, much less prevent certain queries from going out over 
unwanted ones.

This all bears more on the specified solution than the charter, but I 
suspect that (after a reasonable back-and-forth in the ensuing working 
group), one reasonable outcome will be that the mechanism works over 
HTTPS in general, simply because it will be too much of an 
implementation burden to prevent it from doing so.

I'd rather not preclude the ability to have that discussion in the 
working group by foreclosing it in the charter language.