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

Howdy,

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

On Fri, Sep 15, 2017 at 8:44 AM, The IESG <iesg-secretary@ietf.org> 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 (iesg@ietf.org) by 2017-09-25.
>
> DNS Over HTTPS (doh)
> -----------------------------------------------------------------------
> Current status: Proposed WG
>
> Chairs:
>   TBD
>
> Assigned Area Director:
>   Adam Roach <adam@nostrum.com>
>
> Applications and Real-Time Area Directors:
>   Adam Roach <adam@nostrum.com>
>   Ben Campbell <ben@nostrum.com>
>   Alexey Melnikov <aamelnikov@fastmail.fm>
>
> Mailing list:
>   Address: doh@ietf.org
>   To subscribe: https://www.ietf.org/mailman/listinfo/doh
>   Archive: https://mailarchive.ietf.org/arch/browse/doh/
>
> Group page: https://datatracker.ietf.org/group/doh/
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-doh/
>
> 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
> DTLS)
> experience problems.  The working group will re-use HTTPS methods, error
> codes, and other semantics to the greatest extent possible.  The use of
> HTTPS
> 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.

regards,

Ted Hardie