Subject: [DNSOP] Roman Danyliw's No Objection on draft-ietf-dnsop-svcb-https-08: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 28 Feb 2022 13:24:12 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-svcb-https-08: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Kyle Rose for the security feedback in the TSVART review.

** Section 2.1.  Per the ABNF (with the caveat that my manual review of such
syntax might be rusty):

--  What role does “value = *OCTET” play in the specification of SvcParams?  It
doesn’t appear to be used or explained.

-- Should a top-level ‘SvcParams’ rule be defined (i.e., define the formal
syntax of the entire parameter which is a list of SvcParam)?

-- (Editorial) To make it clear that “char-string” is defined in Appendix A, it
would be helpful to:

OLD
SvcParamValue = char-string

NEW
SvcParamValue = char-string    ; per Appendix A

** Section 3.1.  Recommend explicit saying which connection should be abandoned
– s/the client SHOULD abandon the connection attempt/the client SHOULD abandon
the connection attempt to the target service/

** Section 7.4.  Unpacking the first paragraph for easier commentary:

(a)   The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients
   MAY use to reach the service.

(b) If A and AAAA records for TargetName
   are locally available, the client SHOULD ignore these hints.

(c) Otherwise, clients SHOULD perform A and/or AAAA queries for
   TargetName as in Section 3, and clients SHOULD use the IP address in
   those responses for future connections.

(a) seems to be saying that the value of the SrcParamValue is going to return
an IP address associated with a TargetName. (b) seems to be saying that if the
client already has an IP address for the TargetName in the cache, then ignore
the hints.  Per (c), why would A/AAAA queries need to be performed to resolve
TargetName?  Isn’t the hint the associated IP address?

** Section 9.3.  Editorial.  s/the the/the/

** Section 10.  Editorial.  s/the value of the parameter is an ECHConfigList
[ECH]/ the value of the parameter is an ECHConfigList per Section 4 of [ECH]

** Section 10.  Editorial. s/ProtocolNameList in Section 7.1/ ProtocolNameList
in Section 7.1.2/

** Section 10.2. s/smaller SvcPriority/lower SvcPriority value/

** Section A.1  Per the ABNF:
-- What role does “item” rule play?  It’s not referenced or explained.  (see
below)

-- It would be useful to state somewhere which ABNF rule corresponds to which
form of the list.  Perhaps something like:

OLD
   For implementations that allow "," and "\" in item values, the
   following escaping syntax applies:

NEW
For implementations that allow "," and "\" in item values, the  
‘comma-separated’ rule for the escaping syntax applies.  For those that do not
required escaping, the ‘item’ syntax rule applies.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 28 Feb 2022 17:19:20 -0500

Thanks for the review, Roman.  I've responded to the questions inline, and
tracked the suggestions at
https://github.com/MikeBishop/dns-alt-svc/issues/364.

> doesn’t appear to be used or explained.

It's intended be used in the paragraph that follows:

   The SvcParamValue is parsed using the character-string decoding
   algorithm (Appendix A), producing a value.  The value is then
   validated and converted into wire-format in a manner specific to each
   key.

The point of this is to emphasize that conversion proceeds in two stages:
first char-string to *OCTET via key-independent escaping, and then *OCTET
to a type-specific wire-format via a key-specific parser.  Maybe this would
be clearer if "value" were quoted?  It's code-formatted in the HTML
rendering.

Does anyone know if there is a way to make something quoted in the
TXT output and code-formatted in the HTML output?  Or is that discouraged
to avoid discrepancy between the renderings?

> syntax of the entire parameter which is a list of SvcParam)?

This is difficult because the zone-file syntax is nontrivial (and has never
been formally specified!).  For example, SvcParams can span multiple lines
(via the zone file's parenthesis continuation syntax), and those lines can
each have comments on them.

> TargetName?  Isn’t the hint the associated IP address?

Yes, but the hints are "less authoritative" than an actual A/AAAA record,
so we want to minimize reliance on them.  For example, if a CDN customer
publishes a ServiceMode record containing IP hints, they're probably
hardcoded and don't reflect the CDN's best load-balancing decisions.

The purpose of the A/AAAA queries is to populate the local cache without
blocking the current connection setup, so that future connections use
"better" IP addresses.

> -- What role does “item” rule play?  It’s not referenced or explained.

It's mentioned at the top ("In order to represent lists of items...") and
bottom ("this value would produce a list of three items...").  The latter
one is even code-formatted in the HTML rendering.

As above, perhaps we can make this clearer by quoting "item" (or 'item'...).

-- It would be useful to state somewhere which ABNF rule corresponds to
> which

That's fine with me, but note that the "item" rule doesn't really come into
it.  This would look like:

> For those that do not support escaping, the 'simple-comma-separated'
syntax rule applies.
...
> simple-comma-separated = [item-allowed *("," item-allowed)]