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

Ted Hardie <> Fri, 15 September 2017 16:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DA2D1321D8; Fri, 15 Sep 2017 09:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 4CXPkOBptwHI; Fri, 15 Sep 2017 09:45:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63CB913209C; Fri, 15 Sep 2017 09:45:30 -0700 (PDT)
Received: by with SMTP id r141so2600421qke.2; Fri, 15 Sep 2017 09:45:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MeYog05+MGKZxcs98gXl0GlhxcJ4zGqkj3TsawU0dpw=; b=BNd7xxLHePsVoMLsmPP4OlxOn8dSH1Aso3mFhen2+FCS7AHQ7RXnqSCQSbtuxh7MF9 KvoLBbc3pCQCuYsihFCu0ICsehR3vJrAPfHqTBauM+txJSPSSu17So2OBrI5AMMyS9vz DKXE9ye8McTQCBq4ZhYGtSNSXyHG7jq6j5WWLT6kEg4oVATTKXzeUFjKcVI65YVErpeu VVpGeYKTQgmO22dpTdhUAEcHcn+lILOMnRS8KyA5vUdMK4j78CJUmnFKH/TSe+avUfPy jtPeZ+JnyX2pdB1nuVbJNq0325egTx2oWYV/d74aXDO+kp4Bp6SoABD4924HqgfpZJzu 9kfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MeYog05+MGKZxcs98gXl0GlhxcJ4zGqkj3TsawU0dpw=; b=CosJHTwkPxhE9XJtylugoAZemg4lO3YmgxMdM4/YdVN05s/dCwFWyvxLviwzmffNRs 7RxMlMTM0939IxBIfen6hLVBR6Nt77d0Ce8tH26EcSKQ5qvPJPUMY6k1se81jPQCq5Hf /it+YxeT4QfJSAV5wt1+PTcADPhv+LCIVL4Yxboi2oKORa8aCPZ5HiES1uij6n/Z+YRg rJGcnqbaDfg6B0EyBJxRJ/UF/Cyz7XcXcxZX4UVS9t20n/LSmadxzdbKMSYHJoeRYBk+ B7XfmJgnVnJhPGMCNdh+r8evo/k3ufQZIpbdBPZuUeLQPl78686f3JsT06Z7GxmqAkVJ vR3g==
X-Gm-Message-State: AHPjjUh20lx1CoILvv40n2J18242gJX07kicwMV05wKlxoOkKYfqfEVR VIH53flSdXsSDwb8Wlc0BXuAbgr2e1rRrzerWWzAuA==
X-Google-Smtp-Source: AOwi7QDFKPFAxVuSM8x9lGeiOpBV+4KmnnRSYZQUuWjPJSZvhuOh1nG4NPQgZ0JO5CPREdT9IsrjIyVTOA8dtfg/Pbo=
X-Received: by with SMTP id b19mr8113450qka.218.1505493928997; Fri, 15 Sep 2017 09:45:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 15 Sep 2017 09:44:58 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Ted Hardie <>
Date: Fri, 15 Sep 2017 09:44:58 -0700
Message-ID: <>
To: IETF <>
Content-Type: multipart/alternative; boundary="001a1147957ed9798e05593d1ef3"
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 16:45:33 -0000


There are a couple of points that I'd like to raise here.

On Fri, Sep 15, 2017 at 8:44 AM, The IESG <> wrote:

> A new IETF WG has been proposed in the Applications and Real-Time Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your
> comments to the IESG mailing list ( by 2017-09-25.
> DNS Over HTTPS (doh)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> Chairs:
>   TBD
> Assigned Area Director:
>   Adam Roach <>
> Applications and Real-Time Area Directors:
>   Adam Roach <>
>   Ben Campbell <>
>   Alexey Melnikov <>
> Mailing list:
>   Address:
>   To subscribe:
>   Archive:
> Group page:
> Charter:
> This working group will standardize encodings for DNS queries and responses
> that are suitable for use in HTTPS. This will enable the domain name system
> to function over certain paths where existing DNS methods (UDP, TLS, and
> experience problems.  The working group will re-use HTTPS methods, error
> codes, and other semantics to the greatest extent possible.  The use of
> provides integrity and confidentiality, and it also allows the transport to
> interoperate with common HTTPS infrastructure and policy.
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.  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.

I will confess a bias here: while I think it is useful to match the
capability set of HTTP over QUIC to that of HTTP over other transports as
much as possible, I think making that a key part of this work is not a good
initial direction.  For one thing, there are some aspects of the QUIC
transport that are still in discussion, and I think it will slow this work
a bit to track those.  More importantly, though, I think this would be the
wrong way to do DNS over QUIC (draft-huitema-quic-dnsoquic-00 shows a
different approach).  Having QUIC be an early focus here may solidify an
approach that is simple, but not nearly as complete as we could deliver
with a DNS over QUIC.

(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).

The working group will coordinate with the DNSOP and INTAREA working groups
> for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics,
> respectvely. In particular, DNSOP will be consulted for guidance on the
> operational impacts that result from traditional host behaviors (i.e.,
> stub-resolver to recursive-resolver interaction) being replaced with the
> specified mechanism.
> 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.

> The working group will use draft-hoffman-dispatch-dns-over-https as input.
> Milestones:
>   Apr 2018 - Submit specification for performing DNS queries over HTTPS to
>   the IESG for publication as PS
I admire the optimism in this.


Ted Hardie