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

[Benjamin Kaduk <[e-mail]>]

Hi Ben,

Also inline...

On Wed, Mar 02, 2022 at 02:42:37PM -0500, Ben Schwartz wrote:
> 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]> 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".

Ah, good point.  I think I've even seen a few of those myself, but only
managed to think of "serve the same content just not over TLS" examples
when I was writing this.

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

I left some comments there, including noting that I put up a candidate
"more visible change" at https://github.com/MikeBishop/dns-alt-svc/pull/374

> ----------------------------------------------------------------------
> > 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`).
> 
> 
> (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.

Okay, thanks for sharing the rationale.

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

I agree that recent codepoints have ended up meeting this requirement, so a
"wait and see" approach may reveal that it's not worth worrying about.

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

I got a reply from Amanda that IANA had missed this requirement in their
initial review and it sounds like they're not actually comfortable with it
in this case, and Murray has promoted the topic to a DISCUSS, so it should
probably be handled in that thread.

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

Given the prompting to look again, I don't think it's ambiguous.  That
said, since other specifications go the other way and mandate using the
non-generic syntax for core protocol features, some implementors might come
to things with a different mindset.  I would not oppose adding a sentence
to reiterate that this applies to all types, even ones defined in this
document, but I also don't insist on it being added.


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

I think one could argue that whether or not to have the implementation
enforce mandatory requirements is "just" a quality-of-implementation issue
and not required by the spec, but I think I am going to defer to Francesca
and Murray for further discussion of this topic.

Thank you for explaining the history of how we got here.

> 
> >   Does it ever make sense to cause such a
> > loop?
> >
> 
> No.
> 
>    Using AliasMode maintains a separation of concerns: the owner of
> >    foosvc.example.net can add or remove ServiceMode SVCB records without
> >    requiring a corresponding change to example.com.  Note that if
> >    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 CNAME foosvc.example.net" rather
> > than "example.com CNAME foosvc.example.net"?
> 
> 
> Yes.
> 
> 
> > I wonder if clarifying that
> > it's not "example.com CNAME 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.

It sounds like this could be "limit validation to the constraints specified
in this document", then?

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

My point here was just that the client behavior could expose the requested
name to a DNS resolver whereas client behavior prior to SVCB would only
expose the name to the proxy.  Depending on the situation, the exposure
might be acceptable, so in that sence it is a "security[-relevant]
consideration" that the client should be aware of.

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

Ok.

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

Excellent.

Thanks,

Ben