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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 01 Mar 2022 19:18:18 -0800

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

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

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

Section 1.2

   In ServiceMode, the SvcParams of the SVCB RR provide an extensible
   data model for describing alternative endpoints that are
   authoritative for the origin, along with parameters associated with
   each of these alternative endpoints.

(editorial) Since the term "origin" has a specific meaning in the HTTP
context, and this document covers both the generic SVCB and the
HTTP-specific HTTPS records, but this section is supposed to be the
"generic" one, I wonder if we can come up with a different term than
"origin" to use here.  Would "service" or a derived term be consistent
with our definitions?

Section 2.1

   The presentation format of the record is:

   Name TTL IN SVCB SvcPriority TargetName SvcParams

   The SVCB record is defined specifically within the Internet ("IN")
   Class ([RFC1035]).

Should we say something about how "Name" and "TTL" have the same meaning
as in RFC 1035?

   alpha-lc      = %x61-7A   ;  a-z
   SvcParamKey   = 1*63(alpha-lc / DIGIT / "-")
   SvcParam      = SvcParamKey ["=" SvcParamValue]
   SvcParamValue = char-string
   value         = *OCTET

I'd suggest putting some comments in the ABNF that <char-string> is
defined in Appendix A and that <value> and <char-string> are related as
described in the prose.

   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?  (Not that parsing DNS
presentation format is the best thing to do in the first place, but it
surely happens...)

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"?  Does it ever make sense to cause such a
loop?

   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"?  I wonder if clarifying that
it's not "example.com CNAME foosvc.example.net" is worthwhile.

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

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?

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?

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"?  I might consider splitting into two paragraphs, even though
my general preference is to avoid single-sentence paragraphs.

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?

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

Section 9.4

   Clients MUST NOT use an HTTPS RR response unless the client supports
   TLS Server Name Indication (SNI) and indicates the origin name when
   negotiating TLS.  This supports the conservation of IP addresses.

I could sort-of see a misreading of this that says you have to put the
real origin in the SNI extension and not use ECH with a separate fronting
origin.  Maybe we want to say something about "uses SNI (possibly in
conjunction with ECH) to indicate the origin name"?

Section 11.2

   queries for TargetName in advance (see Section 5).  Unless otherwise
   specified, the convention is to set TargetName to the service name
   for an initial ServiceMode record, or to "." if it is reached via an
   alias.  For foo://foo.example.com:8080, this might look like:

I think it would be helpful to show an example of the "set TargetName to the
service name for an initial ServiceMode record" in addition to the alias
example that is shown.

Section 11.3.3

   Suppose that svc.example's default server pool supports HTTP/2, and
   it has deployed HTTP/3 on a new server pool with a different
   configuration.  This can be expressed in the following form:

   $ORIGIN svc.example. ; A hosting provider.
   pool  7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..."

The prose suggests that perhaps the new pool is h3-only and doesn't support
HTTP/2, but the actual example lists both alpn values.  I guess it also omits
no-default-alpn, so the new pool actually supports all three http versions...

Section 11.3.4

   *  The A, AAAA, and HTTPS resolutions are independent lookups, so
      clients may observe and follow different CNAMEs to different CDNs.
      Clients may thus find a TargetName pointing to a name other than
      the one which returned along with the A and AAAA lookups and will
      need to do an additional resolution for them.  [...]

(editorial) I think something went awry near "the one which returned along
with", as it's not even clear whether there are separate queries vs
additional-section responses in the intended scenario.

Section 13

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

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)?

Section 15.3.2

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

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

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.

Section 17.1

Why is [DNAME] classified as normative?  I only see one reference to it,
in a list of examples of possible ways that resolvers might follow
aliases, which does not seem like a "protocol feature" of this document.

I could also perhaps see an argument that references to [HSTS] are just by
way of analogy or indicating that we provide equivalent behavior, which
would not seem to require the reader to understand [HSTS] in order to
implement this specification.

RFC 6147 is referenced only as part of a "MUST NOT perform DNS64"
construction, which seems to indicate that it is *not* a normative
reference.

Appendix D.2

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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 02 Mar 2022 14:46:05 +1100

> deliberate consideration.

Your point about highlighting more than loss of functionality is a good one.  The idea that request semantics might be altered by swapping the scheme is far more relevant.

That said, I'm comfortable with deploying with the upgrade requirement as stated.  While we did have a number of examples where the assumed HTTP<->HTTPS equivalence did not hold in the past, the diminishing share of cleartext HTTP usage is overwhelmingly the vestiges that do not have any HTTPS service on the same name.  

As noted, those servers with a need to maintain distinct resources that differ only in scheme simply cannot use the HTTPS RR.  That is entirely appropriate.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 1 Mar 2022 19:53:21 -0800

> As noted, those servers with a need to maintain distinct resources that differ only in scheme simply cannot use the HTTPS RR.  That is entirely appropriate.

For clarity, I'm also comfortable with the upgrade requirement as stated;
this discuss was intended to just relate to how and how much we talk about
the requirement.

-Ben

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 2 Mar 2022 14:42:37 -0500

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.

...

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

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

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)

> 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

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

> values that are unusable as a result of this restriction?

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

>   I'm somewhat

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

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

> allocations are "shall issue" provided the MUST is satisfied would be more

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/

...

> "keyNNNNN" for key types defined in this document?
>

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

...

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

> than "example.com CNAME foosvc.example.net"?

Yes.

> I wonder if clarifying that

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

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)

> validation in the document that defines the SvcParam in question, or

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
> 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
> protocols"?

Correct.

>   I might consider splitting into two paragraphs, even though

Added to editorial issues.

> Is this intentionally excluding SCTP/DCCP/etc?

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

Section 9.3
> "ech" SvcParam as well?

Yes.

>   I'm a little confused at why the RFC 7838

Added to editorial issues.

...

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

> to include similar discussion or otherwise mention this topic (e.g., by

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

Section 15.3.2
> 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
> 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/ )

...

> trusting that this document has received ample review already.]

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

---

From: Amanda Baber <[email-masked]>
Date: Wed, 2 Mar 2022 20:03:12 +0000

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 <[email-masked]> on behalf of Ben Schwartz <bemasc=[email-masked]>
Date: Wednesday, March 2, 2022 at 11:43 AM
To: Benjamin Kaduk <[email-masked]>
Cc: Tim Wicinski <[email-masked]>, dnsop <[email-masked]>, dnsop-chairs <[email-masked]>, The IESG <[email-masked]>, <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
...
While there is a caution in §9.5 that:

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

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.

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

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

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

  I'm somewhat

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

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/

...

...
Section 2.4.2

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:

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.

Section 3.1

Section 4.3

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

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

Section 7.1.2

Correct.

Section 7.2

Section 9.3

Yes.

...
Section 13

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 think the current text ("SVCB/HTTPS RRs are intended for distribution over untrusted channels...") is clear enough.

Section 15.3.2

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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Mar 2022 13:42:42 -0800

Hi Ben,

Also inline...

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

> 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

> CNAME-at-apex.  CNAME doesn't change the original port number, so logically

Okay, thanks for sharing the rationale.

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

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

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

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

> sequence of 1-255 octets") as opposed to the full validation of the

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

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

> over untrusted channels...") is clear enough.

Ok.

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

Excellent.

Thanks,

Ben