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

[Ben Schwartz <[e-mail]>]

I don't support breaking the SvcParams into separate RRs across the RRSet.
This would be an extremely inefficient encoding in wire format, and would
conflict with the usual understanding of resource records as independently
meaningful alternatives.  It would also require a dramatic rewrite of a
specification that is now widely deployed.

As for the question of commas, I continue to believe that the current text
is preferable.  I believe that the behavior Dick is advocating for is in
fact the one that was present in the draft until -02 [1], changed here
[2].  We changed this text after receiving complaints from WG members that
the algorithm as specified was too complicated, along with my own
experiences attempting to implement it in multiple codebases that apply
char-string decoding during or before tokenization.

The key question is: how is the zone file parsing supposed to work?  I see
two main options:

One-pass (draft-02):
1. Read the key name up to an "="
2. Load a parser whose behavior depends on the key name
3. Feed this parser characters from the zone file until it declares
completion or error

Two-pass (more recent drafts):
1. Read the key name up to an "="
2. Parse the value as a char-string
3. Pass the char-string parser output to the a key-specific parser for
deeper processing

In one-pass parsing, comma-separated value (CSV) lists are like
dot-separated domain names: first-class entities whose delimiter escaping
is fully integrated into the parsing.  In two-pass parsing, CSV format is
an implementation detail of particular SvcParam registrations, encoded as
data inside plain char-strings in the zone file.

To see why I favor two-pass, consider a SvcParam whose wire format value is
defined to be CBOR, represented as JSON in the zone file.  JSON is defined
as UTF-16, and allows strings containing any character from the Basic
Multilingual Plane.  It also allows various kinds of backslash escaping
including " \" " for quotes within strings, and "\uD834\uDD1E" for extended
unicode codepoints.  A one-pass parser must somehow integrate this into the
flow of zone file parsing.  The easiest way is to simply disable all
RFC1035-style escapes and line-breaks for the duration of the
SvcParamValue, but this is a major breach of standard zone file practice,
and raises questions about how to store UTF-16 characters in a zone file.
Alternatively, we could somehow combine both RFC1035 and JSON escaping, but
if this is even possible, it would seem to require writing a new
RFC1035+JSON hybrid parser.  I also think these behaviors would be
confusing to users, who would have to try to understand how this new
integrated escaping works in order to author zone files containing either
kind of escape.

In two-pass parsing, this is trivial.  One simply parses the value as a
char-string, and feeds the output to a JSON parser.  The resulting
double-escaping may be unattractive, but is commonplace when working with
structured data inside a string.

Another point in favor of two-pass parsing: it makes unknown keys "value
errors" instead of "syntax errors".  In one-pass parsing, when the parser
encounters an unrecognized SvcParamKey, it must stop and fail immediately.
It cannot proceed, because it cannot even continue tokenizing.

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-02#appendix-A.1
[2] https://github.com/MikeBishop/dns-alt-svc/pull/282


On Mon, May 10, 2021 at 8:35 AM Joe Abley <[e-mail]> wrote:

> Hi Pieter,
>
> On 10 May 2021, at 11:23, Pieter Lexis <[e-mail]> wrote:
>
> You then invite the following issues:
>
> Clients need to match the tuple (ownername + prio + target) and get all
> data from all matched rrsets, whereas now you get all that data in one
> piece of rdata.
>
>
> Inviting that issue is also a potential benefit, but I agree that the
> implication exists. For example, the ability to publish sets of SvcParams
> with long TTLs ought to increase the probability of cache hits for that
> data and reduce SVCB response sizes.
>
> A client also can't figure out (if not doing DNSSEC valdiation
> themselves) if you have received all the SVC data for a certain name.
>
>
> A client can't figure out without DNSSEC whether anything they have
> received is correct in, in general. So setting aside that more general
> authentication problem, I don't think it's correct to say that a client
> cannot tell whether they have received a complete RRSet in the answer
> section of a response. It's either there and complete or it's absent (and
> perhaps TC=1 if the reason for its absence is message truncation).
>
> There should be no response possible in an implementation that adheres to
> the protocol in which a truncated RRSet appears in the answer section. If
> we're widening the net to implementations that don't follow the rules then
> I agree anything is possible.
>
>
> Joe
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>