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

Mark Nottingham <mnot@mnot.net> Sat, 16 September 2017 01:51 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D76132C2A; Fri, 15 Sep 2017 18:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=RQb11Z1N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fGqr4cFq
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 LGIv1PvQvKq8; Fri, 15 Sep 2017 18:51:53 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1CC13235A; Fri, 15 Sep 2017 18:51:53 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0EB7D20D9A; Fri, 15 Sep 2017 21:51:53 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 15 Sep 2017 21:51:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; 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= messagingengine.com; 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 [192.168.1.14] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (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 <mnot@mnot.net>
In-Reply-To: <EB3D58DB-1F8D-4E32-AE71-841EBCDDC3CA@vpnc.org>
Date: Sat, 16 Sep 2017 11:51:48 +1000
Cc: Ted Hardie <ted.ietf@gmail.com>, doh@ietf.org, IETF <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF671FDD-97C7-46D7-B5B5-B8DB6DEF08AA@mnot.net>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <CA+9kkMBJAP23GmGf_ix-DMeOMB=Rbas+qsBQhrVwZuA5-Cv7Mg@mail.gmail.com> <EB3D58DB-1F8D-4E32-AE71-841EBCDDC3CA@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/YAorUUqAXfLndF9nBSXmph7gYnM>
X-Mailman-Approved-At: Sat, 16 Sep 2017 02:54:38 -0700
Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh)
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Sep 2017 01:51:56 -0000

On 16 Sep 2017, at 4:24 am, Paul Hoffman <paul.hoffman@vpnc.org> 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 <https://mnot.github.io/I-D/bcp56bis/#used>. 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 <https://datatracker.ietf.org/doc/charter-ietf-doh/00-00/>. 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   https://www.mnot.net/