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@xxxxxxxx> 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@xxxxxxxx) by 2017-09-25.
DNS Over HTTPS (doh)
------------------------------------------------------------ -----------
Current status: Proposed WG
Chairs:
TBD
Assigned Area Director:
Adam Roach <adam@xxxxxxxxxxx>
Applications and Real-Time Area Directors:
Adam Roach <adam@xxxxxxxxxxx>
Ben Campbell <ben@xxxxxxxxxxx>
Alexey Melnikov <aamelnikov@xxxxxxxxxxx>
Mailing list:
Address: doh@xxxxxxxx
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.
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