Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-svcb-https-08: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
--
DISCUSS:
--
I'd like to have a (hopefully brief!) discussion about our description of
the "strict transport security" functionality the HTTPS RRtype provides,
with respect to its accuracty/completeness and how explicit vs implicit we
should be about the corresponding divergence from "pure" HTTP behavior.
It's pretty clear that at a pure HTTP protocol level (which as far as I
can tell is the scope of applicability that we claim) that resources
accessed with "http" scheme and resources accessed with "https" scheme
have no intrinsic relationship -- §4.2.2 of
draft-ietf-httpbis-semantics-19 says:
Resources made available via the "https" scheme have no shared
identity with the "http" scheme. They are distinct origins with
separate namespaces. [...]
But the procedures in this document (e.g., §9.5, §9) seem pretty clear
that, when an HTTPS record is published, accesses for "http" scheme
resources should be converted to "https" scheme accesses, with implication
that the client should expect to get the same resource back from the
modified query compared to the unmodified "http"-scheme one.
While there is a caution in §9.5 that:
If this redirection would result in a loss of functionality (e.g.
important resources that are only available on the "http" origin),
the operator MUST NOT publish an HTTPS RR.
but in my reading it leaves some important details as only implicit!
We need to care not only about resources only available on one vs the
other origin, but also about whether the translation would change the
semantics of the client's request/response exchange. That is, whether the
resources accessible by the different schemes are actually analogous
(which, per the above, is not required by HTTP and is subject to the site
administrator's control or in some cases other application protocols on
top of HTTP used by that origin).
This (mostly implicit) requirement is a potential barrier for adoption of
the HTTPS RRtype, and while the precondition is very often going to be
satisfied, I wanted to get a sense for whether we should make the
requirement more explicit, and possibly more prominent in the document
(e.g., mention it in the Introduction). I don't know what the right
answer is, but it seems important enough to ensure that the topic receives
deliberate consideration.
--
COMMENT:
--
First off, thanks for this well-written document! It was pretty clear and
easy to read despite covering some fairly complex logic.
I made a github pull request with some hopefully boring editorial
suggestions: https://github.com/MikeBishop/dns-alt-svc/pull/365
I did have a few high-ish-level thoughts that I either wasn't sure where
to put in the section-by-section comments or wanted to make a bit more
prominent.
The first is a bit hard for me to describe, but basically, when we
construct a QNAME for an SVCB or HTTPS query, we include information
reflecting URI scheme and port, but when we get a TargetName back, that's
been flattened to a single name, in some sense "using up more" of the DNS
hostname namespace under the control of the alternative endpoint then in
the authority's namespace. That is, if I wanted to provide service for
both "foo" and "bar" schemes on two ports each, in order to serve all
four combinations for a single service name, I would need to allocate four
hostnames for alternative endpoints. We do mention this property as it
relates to URI schemes, in §11.1 where we say that "zone owners SHOULD
choose alias target names that indicate the scheme in use", but I didn't
see much discussion of the port-related aspects. I know that the
ServiceMode response can include a port to use in the parameters, so it's
not really a concern about losing flexibility of what ports to use. It
just seems "unbalanced" in some sense that I can't really put my finger
on. On the other hand, it's not like hostnames are a particularly limited
resource, so I don't really see any practical consequences of this setup;
I'm just curious if this is a topic that the WG gave much consideration
to.
I was also struck by the procedure near the end of §3 where we append to
the
