On 15 Sep 2017, at 9:44, Ted Hardie wrote:
=>> 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.
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.
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 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).
Fully agree.
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.
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.
--Paul Hoffman