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

Mark Nottingham <> Sat, 16 September 2017 01:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30D76132C2A; Fri, 15 Sep 2017 18:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=RQb11Z1N; dkim=pass (2048-bit key) header.b=fGqr4cFq
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LGIv1PvQvKq8; Fri, 15 Sep 2017 18:51: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 9C1CC13235A; Fri, 15 Sep 2017 18:51:53 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 0EB7D20D9A; Fri, 15 Sep 2017 21:51:53 -0400 (EDT)
Received: from frontend1 ([]) by compute3.internal (MEProxy); Fri, 15 Sep 2017 21:51:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=iUnT+0AfzkX7ORB672 7dQoBYeiPhQcTzvoD16hNBXJ4=; b=RQb11Z1NzKOPARKaDqFSdfLWQvAr6/z30C UfSWvEIdieXmUmReJ2rnqKWW7YPv6nse4ZOLPW+GmOC9BK22MeX2zBoxTXIkGTeD FgLMqiVIyXX5yE1qjowIM8npRXK77qBowHI6oM7SAm4lonwSw+u6UTLoMEQoBfyY qNkzOHLsJu35DvpvwXInCvb+0fyOPo+ZuLtcrxwWrxzBIFlH4TlA51DRuFL8f0Lj SzA70N0yGxi6YkMhZH0+X90hKrBxDAoTn7g2X99EJz/s/68JTAEHWL/W9xZLRi2g ClcHvRn30rQeBBhzDi4tpB/sGULvA4O5kmQhTDUeVk4k7/BqShOQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=iUnT+0AfzkX7ORB6727dQoBYeiPhQcTzvoD16hNBXJ4=; b=fGqr4cFq Y5ga/TJjP+WFrRBAEHtI3jvNxaKkL38xU1I6jankJNZn8H4uEuBrot9jri+OobxP jfF/pWm58x/bgTfNnReHbkw23BHrSMYFrfhb/jHucLXE92I0tRuFIBSlRnYhcqNc Y2zPaNF0DaUnINr6DdAOtJwXCbwQfTw1GzRLSq9sfvOgy5UPMljgtpQtIqFuKanj yQ6U6AJi1YVW9TCbTPuZ/nfSuBE0d8oNPIP9rbXQ7C4HWIKS1SnpR+vS2YlKvCZA KsIgZCPBd5KS3s+u5sP3IDuv7dHZX5HrlN++yJJQCSP8VqIeLi/T/Z4FSmrbdgmf P56xvAUMH3mEZg==
X-ME-Sender: <xms:uIO8WeJKO_r6SkqNl5PPJrlMJLo3hClHxbGV6-0-mXUh9tih9OoE3g>
X-Sasl-enc: mQDwf9TKya/gW49KITadGp1TjUKURs9oVqrp7ewQ+dCc 1505526712
Received: from [] ( []) by (Postfix) with ESMTPA id 2C97C7E446; Fri, 15 Sep 2017 21:51:50 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Sat, 16 Sep 2017 11:51:48 +1000
Cc: Ted Hardie <>,, IETF <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Paul Hoffman <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
X-Mailman-Approved-At: Sat, 16 Sep 2017 02:54:38 -0700
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: Sat, 16 Sep 2017 01:51:56 -0000

On 16 Sep 2017, at 4:24 am, Paul Hoffman <> wrote:
> On 15 Sep 2017, at 9:44, Ted Hardie wrote:
>> I appreciate the charter's use of "HTTPS" as a signal that these are
>> intended to be TLS-protected HTTP sessions.  I note, however, that there is
>> considerable ambiguity still present.  HTTPS can mean HTTP 1.1 over TLS,
>> HTTP/2 over TLS, and it may mean HTTP over QUIC at some point soon (in some
>> deployments it already means that).  The document named as input specifies
>> HTTP/2  over TLS.  While the working group may, of course, change that to
>> support HTTP 1.1 and/or QUIC, it might be useful for the charter to
>> indicate which of these is potentially in scope.
> 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. If someone wants to create a diff from the eventual protocol for HTTP 1.1, they can do that without forcing the document to add a comparison of the two transports to what is supposed to be a short, concise document.

Whoa; hold it right there. Last I checked, we had only obsoleted HTTP/0.9; 1.1 is still very actively used, still on the standards track, and despite some peoples' wishes, needs and gets attention.

>> If the community is sure
>> now that HTTP over QUIC is in scope, for example, having that noted in the
>> charter by adding the QUIC working group to list of working groups to
>> consult would be useful.
> The deadline for this WG is well ahead of when HTTP-over-QUIC will be finalized. Instead, when HTTP-over-QUIC is finalized, an update to this document should be pretty easy to produce.

I don't understand why anyone thinks anything would be required at all; if QUIC does its job properly, any application defined for HTTP/1.1 or HTTP/2 should work on HTTP-over-QUIC (whatever we end up calling it) without any changes. 

>> (This is in part because of the choice to use the udp wireformat as the
>> baseline HTTP response here, rather than specifying DNS responses over a
>> transport construct like a QUIC stream.  The working group could, of
>> course, change that, but it would seriously shift the direction of its
>> input document to do so).

I interpret the charter to say that this protocol is *using* HTTP, in the sense of <>. In that view, this WG *cannot* change that.

>>> Specification of how the DNS data may be used for new use cases, and
>>> the discovery of the DOH servers, are out of scope for the working group.
>> While it is useful to know that discovery is out of scope here, I think
>> having a quick community discussion now of where it might be in scope is
>> useful.  There are some potentially interesting questions buried in that,
>> especially in how we expect interworking with existing systems to go.
>> Note that even if the service discovery method provides an HTTPS URI for
>> the name server, the questions above related to HTTP version or transport
>> may bite you.  For server discovery based on address and port, the
>> situation is much the same unless the port is clearly marked as TCP or
>> UDP.  And if the server discovery includes no port at all, then a happy
>> eyeballs type method may be needed.
>> This may all fall into a combo of DHCP and DNSOP work, but giving somewhat
>> clean lines for it now seems like it will make the later work go faster.
> If you want to propose a new WG for that, please do so; there are a lot of people interested in that topic. It definitely goes across multiple areas of interest, such as "discovery" and "addressing" and even "trust". Personally, I don't think it applies to a transport document.

I agree that it's a preferable separable rathole.

>>> Milestones:
>>>  Apr 2018 - Submit specification for performing DNS queries over HTTPS to
>>>  the IESG for publication as PS
>> I admire the optimism in this.
> It was not optimistic with the charter that was originally sent to the IESG; see <>. As more issues are added to the charter, it makes sense to have to extend the milestone deliverable.

I'd prefer to keep the current milestone by avoiding additions.

Mark Nottingham