Re: [DNSOP] [Ext] Re: Benjamin Kaduk's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)

[Amanda Baber <[e-mail]>]

Hi,

I can confirm that IANA did miss this text in Section 15.3.1:

The Format Reference
MUST specify how to convert the SvcParamValue's presentation format
to wire format and MAY detail its intended meaning and use.

We can check that a specification exists, but can’t review its contents. If verification of what it specifies is required, the registration procedure needs to be changed to Specification Required. In the meantime, I’ll change this document’s IANA review state to “IANA Not OK.”

Thanks,

Amanda Baber
IANA Operations Manager

From: iesg <[e-mail]> on behalf of Ben Schwartz <bemasc=[e-mail]>
Date: Wednesday, March 2, 2022 at 11:43 AM
To: Benjamin Kaduk <[e-mail]>
Cc: Tim Wicinski <[e-mail]>, dnsop <[e-mail]>, dnsop-chairs <[e-mail]>, The IESG <[e-mail]>, <[e-mail]>
Subject: [Ext] Re: Benjamin Kaduk's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)

Thanks for the deep review, Ben.  I've added your editorial comments to our issue tracker (https://github.com/MikeBishop/dns-alt-svc/issues/369) and responded inline where there were questions.

On Tue, Mar 1, 2022 at 10:18 PM Benjamin Kaduk via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
...
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).

Indeed, I expect that in the common case the resources will _not_ be analogous, because the insecure HTTP endpoint will be blank except for a redirect to "https".  This is it mentions "important resources": a page that says "Please use https instead" is not "important".

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.

I've posted a PR that slightly expands the description of this feature, both in §9.5 and in the introduction (https://github.com/MikeBishop/dns-alt-svc/pull/366).  If you have ideas for a more visible change, I'd be happy to hear them.

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

OK, I've opened a PR to expand the text in §11.1 to discuss port number as well.  The proposed text reads:

When multiple port numbers are in use, it may be
helpful to repeat the prefix labels in the alias target name (e.g.
`_1234._foo.svc.example.net<http://foo.svc.example.net>`).

(https://github.com/MikeBishop/dns-alt-svc/pull/367/files)

I was also struck by the procedure near the end of §3 where we append to
the very end of the priority list an endpoint specified by the final value
of $QNAME combined with the port number from the (original) authority
endpoint.  This seems a strange combination, since the authority port
number is chosen by the origin but the final QNAME will potentially be a
service operator rather far removed from the origin.   Making provision
for what essentially requires a tight coupling between these entities
(when non-default ports are used, at least) feels somewhat at odds with
the stated goal of allowing delegation of operational authority that I
take to imply a more "hands-off" or independently operated approach.
While I understand the utility in picking a single port to use for this
last-ditch entry on the priority list, it doesn't seem like the port from
the original authority is the only choice.  One might imagine using the
default port for the scheme, or the last 'port' SvcParam encountered in
alias chasing, or probably other things as well.

The last sentence in that paragraph provides the rationale:

> This ensures that SVCB-optional clients will make use of an AliasMode record whose TargetName has A and/or AAAA records but no SVCB records.

In other words, this is the behavior that allows AliasMode to act like CNAME-at-apex.  CNAME doesn't change the original port number, so logically this shouldn't either.

I suspect there are some
subtleties here, but I don't think I can think about it in much depth at
the moment, so I hope that the WG has already undertaken such
consideration.

There has been some discussion about the details, e.g. with Kyle Rose (https://github.com/MikeBishop/dns-alt-svc/issues/256).

I found it a bit surprising (though well described and in that sense well
justified) that we limit ourselves to using ALPN values for which the ALPN
value uniquely identifies the suite of protocols to use, most notably
relating to whether TLS or DTLS is used.  That is not something I
typically associate as being a property that ALPN provides, though as I
look through the registry, almost all of the existing entries (that I know
much about) do seem to provide that property.  Do we know of any ALPN
values that are unusable as a result of this restriction?

I'm aware of two: "stun.turn" and "stun.nat-discovery".

  I'm somewhat
curious what the TLS DEs would say if faced with registration requests
designed to "split" an existing ALPN registration so that it would be
usable with SVCB.

I can't speculate on that, but recent codepoints seem to be constructed with the required specificity.  For example, DNS over QUIC has minted a new ALPN ID ("doq") instead of reusing "dot".

The registration procedure for the new Service Parameters registry
(Section 15.3.1) starts off saying that it's FCFS, but accompanies that
with a MUST-level requirement for "MUST specify how to convert the
SvcParamValue's presentation format to wire format" (plus some MAYs as
well).  I'm somewhat surprised that IANA is willing to accept
responsibility for assessing whether the "MUST specify..." has been met.

I was also surprised, but I have learned that IANA does support "FCFS with a mandatory specification field), and does at least glance at the specification to confirm that it _is_ a specification.

Perhaps a policy of Expert Review with directions to the experts that
allocations are "shall issue" provided the MUST is satisfied would be more
appropriate?

That would be fine with me, but note that this was discussed in the working group:
https://mailarchive.ietf.org/arch/msg/dnsop/i_U0MtYuQXT2xeiRMGkzK_pmWrU/

...
   Arbitrary keys can be represented using the unknown-key presentation
   format "keyNNNNN" where NNNNN is the numeric value of the key type
   without leading zeros.  A SvcParam in this form SHALL be parsed as
   specified above, and the decoded value SHALL be used as its wire
   format encoding.

Being SEC AD makes me think about edge cases a lot; do we want to say
anything about whether a parser is required to be able to handle
"keyNNNNN" for key types defined in this document?

It is required ("SHALL").  If you think it's ambiguous, we can emphasize it.

...
Section 2.4.2

   The primary purpose of AliasMode is to allow aliasing at the zone
   apex, where CNAME is not allowed.  In AliasMode, the TargetName will
   be the name of a domain that resolves to SVCB, AAAA, and/or A
   records.  (See Section 6 for aliasing of SVCB-compatible RR types.)
   The TargetName SHOULD NOT be equal to the owner name, as this would
   result in a loop.

Why is this not a "MUST NOT"?

This was originally MUST NOT, but was changed at the request of a BIND maintainer.  I believe the change was motivated by the presumption that any mandatory requirement on an RR must be enforced by the zone file parser if possible, and this would be inconvenient to enforce:

https://mailarchive.ietf.org/arch/msg/dnsop/GQFf4ckTsc0CT9nx5IYHBdc3888/
https://github.com/MikeBishop/dns-alt-svc/issues/221

  Does it ever make sense to cause such a
loop?

No.

   Using AliasMode maintains a separation of concerns: the owner of
   foosvc.example.net<http://foosvc.example.net> can add or remove ServiceMode SVCB records without
   requiring a corresponding change to example.com<http://example.com>.  Note that if
   foosvc.example.net<http://foosvc.example.net> promises to always publish a SVCB record, this
   AliasMode record can be replaced by a CNAME, which would likely
   improve performance.

So this would be "_8080._foo.example.com<http://foo.example.com> CNAME foosvc.example.net<http://foosvc.example.net>" rather
than "example.com<http://example.com> CNAME foosvc.example.net<http://foosvc.example.net>"?

Yes.

I wonder if clarifying that
it's not "example.com<http://example.com> CNAME foosvc.example.net<http://foosvc.example.net>" is worthwhile.

I've added it to our list of editorial concerns.

Section 3.1

For a section titled "Handling resolution failures", perhaps we should
also give guidance on how resolution failures should be handled when DNS
responses are not cryptographically protected?  (I assume "proceed to the
fallback", but for completeness' sake...)

OK, I've proposed additional text:

> If DNS responses are not cryptographically protected, clients MAY treat
> SVCB resolution failure as fatal or nonfatal.

(https://github.com/MikeBishop/dns-alt-svc/pull/368)

Section 4.3

                                     For complex value types whose
   interpretation might differ between implementations or have
   additional future allowed values added (e.g.  URIs or "alpn"),
   resolvers SHOULD limit validation to specified constraints.

I'm not entirely sure what "specified constraints" is intended to mean,
here.  Would it be those constrains specified as always suitable for
validation in the document that defines the SvcParam in question, or
something else?

The idea here was to avoid recursive resolvers attempting to validate whether the contents of a SvcParamValue are "deeply valid", e.g. checking the contents of a URI value to see if it is a valid URI.  This could lead to compatibility failure for complex types where the space of valid options is not entirely obvious (like URIs).  The "specified constraints" are the constraints specified for the SvcParamValue itself (e.g. "contents are a sequence of 1-255 octets") as opposed to the full validation of the contents.

Section 5.2

                                      As a performance optimization, if
   some of the SVCB records in the response can be used without
   requiring additional DNS queries, the client MAY prefer those
   records, regardless of their priorities.

This might be a performance optimization for the initial connection setup
while being a performance de-optimization for the actual application
traffic that goes over the connection (i.e., the authoritative's
priority values might be assumed to provide actual value to the user).
Did the WG discuss whether or not to go into such subtleties here?

This text was originally moved here from the ESNI specification
(https://github.com/MikeBishop/dns-alt-svc/pull/56)

Evidently the authors felt this guidance was important enough to be worth preserving.

Section 7.1.2

   Clients SHOULD NOT attempt connection to a service endpoint whose
   SVCB ALPN set does not contain any supported protocols.  To ensure
   consistency of behavior, clients MAY reject the entire SVCB RRSet and
   fall back to basic connection establishment if all of the RRs
   indicate "no-default-alpn", even if connection could have succeeded
   using a non-default alpn.

(editorial) Just to confirm: these two directives are only related in that
they cover client ALPN handling, and there is no expectation that the "MAY
reject" is preconditioned on "SVCB ALPN set does not contain any supported
protocols"?

Correct.

  I might consider splitting into two paragraphs, even though
my general preference is to avoid single-sentence paragraphs.

Added to editorial issues.

Section 7.2

   The "port" SvcParamKey defines the TCP or UDP port that should be
   used to reach this alternative endpoint.  [...]

Is this intentionally excluding SCTP/DCCP/etc?

I don't think it's intentional, no.

Section 9.3

   Origins that publish an "ech" SvcParam in their HTTPS record SHOULD
   also publish an "ech" SvcParam for any alt-authorities.  [...]

Just to confirm I'm understanding this properly: this is saying that if an
origin publishes an HTTPS RR with an "ech" SvcParam (any single RR in the
RRset suffices to trigger the condition), then the origin should also
publish HTTPS records for any alt-authorities that it would send in an
Alt-Svc header field, and those other HTTPS records should all include an
"ech" SvcParam as well?

Yes.

  I'm a little confused at why the RFC 7838
"alt-authorities" keyword is used here without any specific reference to
Alt-Svc itself.  (There are only three instances of the string
"alt-authorit" in this document, two of which are in this paragraph; the
third is clearly marked as applying to the Alt-Svc usage.)

Added to editorial issues.

...
Section 13

Do we want to mention the discussion in §3.2 about using caution in
resolving SVCB when using a proxy?

Is there a nontrivial security point here?  The only security point I see is that if the client disables SVCB resolution, it will not benefit from SVCB.  That seems obvious enough to not need repeating.

I note that draft-ietf-tls-esni has a note (its §10.2) explaining that
DNSSEC or other protection is not really needed for ECH config, since an
attacker that controls DNS can already defeat ECH protections.  Do we want
to include similar discussion or otherwise mention this topic (e.g., by
reference)?

I think the current text ("SVCB/HTTPS RRs are intended for distribution over untrusted channels...") is clear enough.

Section 15.3.2

   | 65535       | N/A             | Reserved       | (This document) |
   |             |                 | ("Invalid      |                 |
   |             |                 | key")          |                 |

Do we care that 'I' is not a lowercase letter?

Space is not a valid key character either, but we could get rid of the quotes if that would make it clearer that this is not a key name.

Section 15.4

I always worry somewhat when we propose a new mechanism with no worked
examples for it (in this case, protocols using SVCB per the "MUST have an
entry for its scheme" requirement in §12).  Perhaps the HTTPS example is
close enough that my worries are groundless.

The mapping for DNS itself is in WGLC, so hopefully that can serve the purpose. (https://datatracker.ietf.org/doc/draft-ietf-add-svcb-dns/ )

...
Appendix D.2

[I did not carefully review the examples for internal consistency,
trusting that this document has received ample review already.]

Yes, these examples are in unit tests for some implementations.