Subject: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

From: [email-masked]
Date: Wed, 21 Apr 2021 06:51:20 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)
        Authors         : Ben Schwartz
                          Mike Bishop
                          Erik Nygren
	Filename        : draft-ietf-dnsop-svcb-https-05.txt
	Pages           : 56
	Date            : 2021-04-21

Abstract:
   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTPS origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration and keys for encrypting the TLS ClientHello).
   They also enable aliasing of apex domains, which is not possible with
   CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
   origins.  By providing more information to the client before it
   attempts to establish a connection, these records offer potential
   benefits to both performance and privacy.

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/MikeBishop/dns-alt-svc
   (https://github.com/MikeBishop/dns-alt-svc).  The most recent working
   version of the document, open issues, etc. should all be available
   there.  The authors (gratefully) accept pull requests.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 21 Apr 2021 10:13:08 -0400

Thanks for all the great input during WGLC.  Here's the changelog for the
latest draft:

* Specify interaction with EDNS Client Subnet and Additional section caching
* Rename "echconfig" to "ech"
* Add a suite of test vectors (both valid and invalid) and more examples
* Clarify requirements for resolvers' (non-)use of SvcParams
* Clarify guidance regarding default ALPN values

On Wed, Apr 21, 2021 at 9:51 AM <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Wellington, Brian" <[email-masked]>
Date: Wed, 21 Apr 2021 16:43:57 +0000

I’m not a fan of the new text in section 4.3:

Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys or malformed SvcParamValues.

It is perfectly reasonable for a recursive resolver to reject any malformed DNS record.  There’s a significant difference between “malformed” and “unknown”.  A recursive resolver should definitely allow records with unknown SvcParamKeys, but if the format of a record is known, a resolver should be allowed (encouraged, in fact) to check that it conforms to that format.

Brian

On Apr 21, 2021, at 7:13 AM, Ben Schwartz <bemasc=[email-masked]<mailto:bemasc=[email-masked]>> wrote:

Thanks for all the great input during WGLC.  Here's the changelog for the latest draft:

On Wed, Apr 21, 2021 at 9:51 AM <[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

_______________________________________________
DNSOP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 21 Apr 2021 13:00:56 -0400

On Wed, Apr 21, 2021 at 12:44 PM Wellington, Brian <bwelling=
[email-masked]> wrote:

> Recursive resolvers MUST be able to convey SVCB records with unrecognized
> SvcParamKeys or malformed SvcParamValues.
>
>
> It is perfectly reasonable for a recursive resolver to reject any
> malformed DNS record.  There’s a significant difference between “malformed”
> and “unknown”.  A recursive resolver should definitely allow records with
> unknown SvcParamKeys, but if the format of a record is known, a resolver
> should be allowed (encouraged, in fact) to check that it conforms to that
> format.
>

The concern here was about differing interpretations of future standards.
For example, if some SvcParamValue is defined as a URL (for some future
key), implementations are likely to disagree about whether certain
bytestrings are valid URLs.  (There are several definitions and a zillion
edge cases.)  The resolver has no use for these values, so the most
compatible behavior is to treat them as opaque bytestrings.

We very deliberately chose the phrase "MUST be able to convey" to recognize
that resolvers might be configured not to convey a record with a malformed
value, but it should be possible.

Do you think we should change this sentence?

---

From: Petr Špaček <[email-masked]>
Date: Wed, 21 Apr 2021 19:12:38 +0200

On 21. 04. 21 19:00, Ben Schwartz wrote:
> On Wed, Apr 21, 2021 at 12:44 PM Wellington, Brian 
> <bwelling=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>         Recursive resolvers MUST be able to convey SVCB records
>         with unrecognized SvcParamKeys or malformed SvcParamValues.
> 
> 
>     malformed DNS record.  There’s a significant difference between
>     “malformed” and “unknown”.  A recursive resolver should definitely
>     allow records with unknown SvcParamKeys, but if the format of a
>     record is known, a resolver should be allowed (encouraged, in fact)
>     to check that it conforms to that format.
> 
> 
> The concern here was about differing interpretations of future 
> standards.  For example, if some SvcParamValue is defined as a URL (for 
> some future key), implementations are likely to disagree about whether 
> certain bytestrings are valid URLs.  (There are several definitions and 
> a zillion edge cases.)  The resolver has no use for these values, so the 
> most compatible behavior is to treat them as opaque bytestrings.
> 
> We very deliberately chose the phrase "MUST be able to convey" to 
> recognize that resolvers might be configured not to convey a record with 
> a malformed value, but it should be possible.
> 

I can see the same ambiguity as Brian.

What about this text as replacement?
---
Recursive resolvers MUST be able to convey SVCB records with 
unrecognized SvcParamKeys if they conform to RDATA wire format (section 
2.2).
---

What I mean: Resolvers must be able to handle _unknown_ SvcParams as 
opaque byte strings.

Various resolvers will do some sort of filtering on individual params, 
but such filtering is "local policy" and nothing we write into the RFC 
can change local policy anyway. For that reason I would not go to great 
lengths to explain what to do with unrecognized URLs etc.

-- 
Petr Špaček

---

From: "Wellington, Brian" <[email-masked]>
Date: Wed, 21 Apr 2021 17:24:36 +0000

Yes, I think that sentence should be changed.  I’d suggest removing the "malformed SvcParamValues” part, but others may disagree.

I agree that a URL is a tricky case.  The spec writer might not want to include an ABNF representation of a valid URL, because implementors would likely want to use existing facilities to parse URLs, which are likely not consistent.  In that case, though, I would expect the spec to indicate that the field is a bytestring, and the resolver to be able to that.  The fact that it’s a URL is something that the client should be checking.

For the existing parameters, there are checks that can (and should) be made; that IPv4 addresses, IPv6 addresses, and ports are of appropriate length, that the ALPN field has the right length prefix, and that the mandatory field is ordered and has a valid length.

There are also checks which are not specified, and which a client may want to do, but are not part of the record format itself.  I wouldn’t expect a recursive resolver to reject a record containing an ipv4hint with the address 255.255.255.255, but that doesn’t mean that a client should try to connect to it.

I do not think that it should be required that a resolver is able to convey malformed records, where malformed is (only) referring to the syntactic content.  That’s not how resolvers work for other types; no resolvers have options to allow 5 byte A records.

Brian

On Apr 21, 2021, at 10:00 AM, Ben Schwartz <bemasc=[email-masked]<mailto:bemasc=[email-masked]>> wrote:

On Wed, Apr 21, 2021 at 12:44 PM Wellington, Brian <bwelling=[email-masked]<mailto:[email-masked]>> wrote:
I’m not a fan of the new text in section 4.3:

The concern here was about differing interpretations of future standards.  For example, if some SvcParamValue is defined as a URL (for some future key), implementations are likely to disagree about whether certain bytestrings are valid URLs.  (There are several definitions and a zillion edge cases.)  The resolver has no use for these values, so the most compatible behavior is to treat them as opaque bytestrings.

We very deliberately chose the phrase "MUST be able to convey" to recognize that resolvers might be configured not to convey a record with a malformed value, but it should be possible.

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 21 Apr 2021 14:58:49 -0400

On Wed, Apr 21, 2021 at 1:24 PM Wellington, Brian <bwelling=
[email-masked]> wrote:

> Yes, I think that sentence should be changed.  I’d suggest removing the
> "malformed SvcParamValues” part, but others may disagree.
>
> I agree that a URL is a tricky case.  The spec writer might not want to
> include an ABNF representation of a valid URL, because implementors would
> likely want to use existing facilities to parse URLs, which are likely not
> consistent.  In that case, though, I would expect the spec to indicate that
> the field is a bytestring, and the resolver to be able to that.  The fact
> that it’s a URL is something that the client should be checking.
>

But surely by this standard all fields are bytestrings?

For the existing parameters, there are checks that can (and should) be
> made; that IPv4 addresses, IPv6 addresses, and ports are of appropriate
> length, that the ALPN field has the right length prefix, and that the
> mandatory field is ordered and has a valid length.
>
> There are also checks which are not specified, and which a client may want
> to do, but are not part of the record format itself.  I wouldn’t expect a
> recursive resolver to reject a record containing an ipv4hint with the
> address 255.255.255.255, but that doesn’t mean that a client should try to
> connect to it.
>

It sounds like you are suggesting that we distinguish between "how the
resolver should parse the value" and "how the client should parse the
value" ... but the value is meaningless to the resolver, so there is no
particular sense in which the resolver should parse it.  This is not like
JSON, where an intermediary might check that the value of the "url" key is
a string, without checking whether it is a valid URL.  All SvcParamValues
are opaque bytestrings unless you know how to parse them.

> I do not think that it should be required that a resolver is able to
> convey malformed records, where malformed is (only) referring to the
> syntactic content.  That’s not how resolvers work for other types; no
> resolvers have options to allow 5 byte A records.
>

Similarly, there's no requirement here that resolvers be able to convey a
syntactically invalid SvcParams structure (i.e. truncated TLV).  The
requirement is that resolvers are, in general, able to convey records even
if a SvcParamValue does not appear to be valid according to the key's
specification.  This is particularly relevant for multipurpose codebases
that can act as both recursive and authoritative (or client).  Such
codebases must contain full SvcParam validation logic for all recognized
SvcParamKeys, but they must be able to bypass it in recursive mode to avoid
ossification.

This is not a requirement that resolvers always pass through these invalid
values, and in many cases (e.g. "port") the validation is sufficiently
trivial that enforcing it poses minimal compatibility risk.  However, I
think this is worth highlighting because, in my own implementation, it was
easiest to enforce full validation for all recognized keys (present and
future) during recursive resolution, and some extra effort was required to
make sure that invalid values could pass through.

>
> Brian
>
>
> On Apr 21, 2021, at 10:00 AM, Ben Schwartz <
> bemasc=[email-masked]> wrote:
>
> recognize that resolvers might be configured not to convey a record with a
> malformed value, but it should be possible.
>

---

From: "Wellington, Brian" <[email-masked]>
Date: Wed, 21 Apr 2021 19:18:39 +0000

On Apr 21, 2021, at 11:58 AM, Ben Schwartz <bemasc=[email-masked]<mailto:bemasc=[email-masked]>> wrote:

On Wed, Apr 21, 2021 at 1:24 PM Wellington, Brian <bwelling=[email-masked]<mailto:[email-masked]>> wrote:
Yes, I think that sentence should be changed.  I’d suggest removing the "malformed SvcParamValues” part, but others may disagree.

They’re all sequences of bytes, sure.  But all of the defined parameters do have syntactic structure, and resolvers should be allowed to do the same level of syntactic checking for SVCB/HTTPS records as they do for records of other types.  If there’s checking which is clearly out of the scope of the document (like URL validation), that is fundamentally different than checks like “the IPv6 address is 16 bytes”.

It sounds like you are suggesting that we distinguish between "how the resolver should parse the value" and "how the client should parse the value" ... but the value is meaningless to the resolver, so there is no particular sense in which the resolver should parse it.  This is not like JSON, where an intermediary might check that the value of the "url" key is a string, without checking whether it is a valid URL.  All SvcParamValues are opaque bytestrings unless you know how to parse them.

Again, there is a difference between syntax and semantics.  The resolver should be allowed to check that something conforms to the syntax specified in the spec, even if it doesn’t use the value.

Resolvers do not use the contents of most DNS record types, other than the ones which are used part of the DNS protocol itself (NS, A, AAAA, and the DNSSEC records).  That does not mean that it shouldn’t check the formats of other known records when possible.

Similarly, there's no requirement here that resolvers be able to convey a syntactically invalid SvcParams structure (i.e. truncated TLV).  The requirement is that resolvers are, in general, able to convey records even if a SvcParamValue does not appear to be valid according to the key's specification.  This is particularly relevant for multipurpose codebases that can act as both recursive and authoritative (or client).  Such codebases must contain full SvcParam validation logic for all recognized SvcParamKeys, but they must be able to bypass it in recursive mode to avoid ossification.

This is absolutely not true.  Once the format of an rdata type (or a subtype, like an SVCB parameter) is defined, it must not change.  The authors of this spec surely know this, as there was a lot of discussion about the incompatibility of the echconfig->ech change, and how something like this could never happen in a standardized type.  A correctly implemented resolver should never reject a valid parameter as invalid, and if there is a need to change what the definition of a valid parameter is, that requires defining a new parameter type.

This is not a requirement that resolvers always pass through these invalid values, and in many cases (e.g. "port") the validation is sufficiently trivial that enforcing it poses minimal compatibility risk.  However, I think this is worth highlighting because, in my own implementation, it was easiest to enforce full validation for all recognized keys (present and future) during recursive resolution, and some extra effort was required to make sure that invalid values could pass through.

It’s a requirement that recursive resolvers introduce new behavior to allow the avoidance of format validation for SVCB records.  You’re free to implement that in your own code, but it’s an onerous requirement for other implementors.

Changing the text to:

Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys, and
MAY be able to convey SVCB records with malformed SvcParamValues.

would be fine with me, and I’d ignore the MAY part.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 21 Apr 2021 15:51:01 -0400

Here's a proposed text change that I hope can satisfy both of our
requirements: https://github.com/MikeBishop/dns-alt-svc/pull/319

The key sentence is:

To ensure compatibility with complex SvcParam specifications, recursive
resolvers MAY validate the values of recognized SvcParamKeys, but MUST NOT
reject the record on this basis unless a value is obviously invalid.

On Wed, Apr 21, 2021 at 3:18 PM Wellington, Brian <bwelling=
[email-masked]> wrote:

>
>
> On Apr 21, 2021, at 11:58 AM, Ben Schwartz <
> They’re all sequences of bytes, sure.  But all of the defined parameters
> do have syntactic structure, and resolvers should be allowed to do the same
> level of syntactic checking for SVCB/HTTPS records as they do for records
> of other types.  If there’s checking which is clearly out of the scope of
> the document (like URL validation), that is fundamentally different than
> checks like “the IPv6 address is 16 bytes”.
>
>
>> There are also checks which are not specified, and which a client may
>> want to do, but are not part of the record format itself.  I wouldn’t
>> expect a recursive resolver to reject a record containing an ipv4hint with
>> the address 255.255.255.255, but that doesn’t mean that a client should try
>> to connect to it.
>>
>
> Again, there is a difference between syntax and semantics.  The resolver
> should be allowed to check that something conforms to the syntax specified
> in the spec, even if it doesn’t use the value.
>
> Resolvers do not use the contents of most DNS record types, other than the
> ones which are used part of the DNS protocol itself (NS, A, AAAA, and the
> DNSSEC records).  That does not mean that it shouldn’t check the formats of
> other known records when possible.
>
>
>
> This is absolutely not true.  Once the format of an rdata type (or a
> subtype, like an SVCB parameter) is defined, it must not change.  The
> authors of this spec surely know this, as there was a lot of discussion
> about the incompatibility of the echconfig->ech change, and how something
> like this could never happen in a standardized type.  A correctly
> implemented resolver should never reject a valid parameter as invalid, and
> if there is a need to change what the definition of a valid parameter is,
> that requires defining a new parameter type.
>
> It’s a requirement that recursive resolvers introduce new behavior to
> allow the avoidance of format validation for SVCB records.  You’re free to
> implement that in your own code, but it’s an onerous requirement for other
> implementors.
>
> Changing the text to:
>
> SvcParamKeys, and
>> certain bytestrings are valid URLs.  (There are several definitions and a
>> zillion edge cases.)  The resolver has no use for these values, so the most

---

From: "Wellington, Brian" <[email-masked]>
Date: Wed, 21 Apr 2021 19:58:49 +0000

That looks good to me.

Brian

On Apr 21, 2021, at 12:51 PM, Ben Schwartz <bemasc=[email-masked]<mailto:bemasc=[email-masked]>> wrote:

Here's a proposed text change that I hope can satisfy both of our requirements: https://github.com/MikeBishop/dns-alt-svc/pull/319

The key sentence is:

To ensure compatibility with complex SvcParam specifications, recursive resolvers MAY validate the values of recognized SvcParamKeys, but MUST NOT reject the record on this basis unless a value is obviously invalid.

On Wed, Apr 21, 2021 at 3:18 PM Wellington, Brian <bwelling=[email-masked]<mailto:[email-masked]>> wrote:

Changing the text to:

Brian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Apr 2021 20:18:13 +0000

> To ensure compatibility with complex SvcParam specifications, recursive resolvers MAY validate the values of recognized SvcParamKeys, but MUST NOT reject the record on this basis unless a value is…

Obvious to whom? "I know it when I see it" is not a good way to make standards. Also, validating SvcParamKeys does not ensure compatibility with complex SvcParam specifications. 

A different, simpler proposal:

   Recursive resolvers MAY validate the values of recognized SvcParamKeys
   in a record, and MAY reject records with invalid SvcParamKeys. 

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 27 Apr 2021 13:32:03 -0700

On Wed, Apr 21, 2021 at 1:18 PM Paul Hoffman <[email-masked]> wrote:

> Obvious to whom? "I know it when I see it" is not a good way to make
> standards. Also, validating SvcParamKeys does not ensure compatibility with
> complex SvcParam specifications.
>

I've updated the PR to say this:

Recursive resolvers MAY validate the values of recognized SvcParamKeys and
reject records containing invalid values. However, for complex value types
whose interpretation might differ between implementations (e.g. URIs),
resolvers SHOULD limit validation to basic sanity checks.