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

From: Dick Franks <[email-masked]>
Date: Sun, 2 May 2021 16:25:18 +0100

All,

I have considerable difficulty with these test vectors at the end of
Appendix D.2:

        16 foo.example.org. alpn="f\\\\oo\\,bar,h2"
        16 foo.example.org. alpn=f\\\092oo\092,bar,h2

        \# 35 (
        00 10                                              ; priority
        03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
        00 01                                              ; key 1
        00 0c                                              ; param length 12
        08                                                 ; alpn length 8
        66 5c 6f 6f 2c 62 61 72                            ; alpn value
        02                                                 ; alpn length 2
        68 32                                              ; alpn value
        )

which appear to be incompatible with RFC1035 5.1 paragraph 10:

        Because these files are text files several special encodings are
        necessary to allow arbitrary data to be loaded.  In particular:

        ...

        \X          where X is any character other than a digit (0-9), is
                    used to quote that character so that its special meaning
                    does not apply.  For example, "\." can be used to place
                    a dot character in a label.

        \DDD        where each D is a digit is the octet corresponding to
                    the decimal number described by DDD.  The resulting
                    octet is assumed to be text and is not checked for
                    special meaning.

The intention appears to be to include (a) a single arbitrary octet in
the argument, and (b) a plain text comma not being a delimiter in the
argument list. The specimen result is consistent with that assumption.

Armed with the weapons supplied by RFC1035, the obvious way to
represent such an argument is:   alpn="f\092oo\,bar,h2"

A parser adhering strictly to RFC1035 zone file escape conventions:

        #!/usr/bin/perl
        use Net::DNS 1.31;
        use Net::DNS::ZoneFile;

        my $zonefile = new Net::DNS::ZoneFile(\*DATA);
        while ( my $rr = $zonefile->read ) {
            $rr->print;
        }
        exit;

        __DATA__
        rfc1035-compliant.example.  SVCB    16 foo.example.org.
alpn="f\092oo\,bar,h2"

produces the desired wire-format image:

        rfc1035-compliant.example.  IN      SVCB    ( \# 35 0010    ; 16
                03666f6f076578616d706c65036f7267 00         ; foo.example.org.
                0001 000c 08665c6f6f2c626172026832 )

Other parsers are available.

The test vectors, as written, appear to rely upon somehow reactivating
the special meaning of the escape character which is explicitly
disallowed by RFC1035.

The result in each case is:

        non-compliant.example.      IN      SVCB    ( \# 37 0010    ; 16
                03666f6f076578616d706c65036f7267 00         ; foo.example.org.
                0001 000e 06665c5c6f6f5c03626172026832 )

the escaped escape characters being inserted as uninterpreted text per RFC1035.

Dick Franks
________________________

---

From: Mark Andrews <[email-masked]>
Date: Mon, 3 May 2021 10:27:40 +1000

I agree with you Dick, but some developers complained that they "couldn’t
re-use their string parsers" (despite no existing parser supporting key=“value”)
so now we have to double escape backslashes.  I very much feel that this is tail
wagging the dog.

> On 3 May 2021, at 01:25, Dick Franks <[email-masked]> wrote:
> 
> All,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 3 May 2021 10:23:00 -0700

The purpose of this two-layer escaping is to allow key-independent
tokenizing of SvcParam values.  For example, I just wrote an implementation
of the parser that works as follows:

1. Tokenize
  a. Scan forward looking for whitespace or "=".  This is the key name.
  b. If "=" was found, run the standard char-string parser.  Its output is
the SvcParam presentation value.
2. Create a SvcParam representing (key name, value).
  a. Choose a value parser based on the key name.
    - Parsers that use the "value-list" pattern call a subroutine with a
tiny chunk of escaping logic for handling backslash and comma.
  b. Run the parser on the value.

If we use single-layer escaping, this arrangement is not possible.  Instead,
(1) we would need to add complexity to the char-string parser that is
shared by many RR types.
(2) we would need to integrate key-type-specific behavior into the
tokenizer, complicating the interface between the parsing function and the
SvcParams implementation.

In the draft's arrangement, those implementation choices are allowed, but
not required.

For the administrators, this all seems likely to remain irrelevant.  There
is no known use case where escaping is or will be used in a value-list
element.  The functionality is defined only to preserve ALPN as
8-bit-clean, as requested by some TLS experts, but there will likely never
be a defined ALPN that contains these characters.

On Sun, May 2, 2021 at 5:27 PM Mark Andrews <[email-masked]> wrote:

> >        00 0c                                              ; param length
> 12
> PHONE: +61 2 9871 4742 <+61%202%209871%204742>              INTERNET:
> [email-masked]
>
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 4 May 2021 12:07:20 +1000

Again this is tail wagging the dog.  It should all be about ease of data entry.
Adding another backslash escape with meaning should be trivial.  It was in BIND.
It was no harder than handling \. in a DNS label.  Instead we have complicated data
entry.

Making it easy for millions of people entering data vs a handful of people writing
parsers.

B.T.W. port=“\055\053” is illegal and I suspect that some of the parsers requiring the
double quoting don’t detect that.  See the various "SvcParamValue MUST NOT contain escape
sequences”. 

Mark

> On 4 May 2021, at 03:23, Ben Schwartz <[email-masked]> wrote:
> 
> The purpose of this two-layer escaping is to allow key-independent tokenizing of SvcParam values.  For example, I just wrote an implementation of the parser that works as follows:
> 
> 1. Tokenize
>   b. If "=" was found, run the standard char-string parser.  Its output is the SvcParam presentation value.
>     - Parsers that use the "value-list" pattern call a subroutine with a tiny chunk of escaping logic for handling backslash and comma.
> (1) we would need to add complexity to the char-string parser that is shared by many RR types.
> (2) we would need to integrate key-type-specific behavior into the tokenizer, complicating the interface between the parsing function and the SvcParams implementation.
> 
> In the draft's arrangement, those implementation choices are allowed, but not required.
> 
> For the administrators, this all seems likely to remain irrelevant.  There is no known use case where escaping is or will be used in a value-list element.  The functionality is defined only to preserve ALPN as 8-bit-clean, as requested by some TLS experts, but there will likely never be a defined ALPN that contains these characters.
>

---

From: Dick Franks <[email-masked]>
Date: Tue, 4 May 2021 20:08:25 +0100

>   b. Run the parser on the value.

Thanks for the explanation.

The brutal reality is that the char-string parser has already
obliterated the distinction between escaped and unescaped commas
before the value-list parser is invoked.

> In the draft's arrangement, those implementation choices are allowed, but not required.

By publishing test vectors including escaped escapes effectively makes
these required, inflicting your questionable design choice on other
developers who opted for a different strategy.

> For the administrators, this all seems likely to remain irrelevant.  There is no known use case where escaping is or will be used in a value-list element.  The functionality is defined only to pres…

If you truly believe that, then the pragmatic solution is to accept
the unfortunate fact that your implementation is limited to
value-lists not containing escaped commas.  The residual risk that
someone, somewhere, will discover a need for an escaped comma is
likely to be small.  At worst, you will need to revisit your design,
at best you need do nothing at all.

For the sanity of all concerned, SVCB should adhere to the same
standard RFC1035 escape conventions as the other 50+ RRTYPEs.

Regards

--Dick

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 4 May 2021 13:18:18 -0700

> before the value-list parser is invoked.

Yes, hence the use of "\\," for embedded commas in value-list values.

> these required,

To be clear, it is the text of the document, not the test vectors, that
creates this requirement.  The test vectors merely complement the normative
requirements, which already detail this arrangement.

...

> standard RFC1035 escape conventions as the other 50+ RRTYPEs.

I think that's a good description of why this arrangement was chosen.
Lifting comma-handling up into the char-string parser would result in SVCB
using a _different_ escape convention from all the other RR types.  This
arrangement ensures that, to the extent possible, SVCB uses the _same_
escaping as all the other RR types.  It also ensures that all the SvcParams
use the same basic parser.

Value-list parsing is a detail, not of SVCB, but of certain SvcParam types
within SVCB.  Consider a future SvcParam whose presentation value is
defined to be JSON.  Shall we require that the zone file parser switch to
JSON mode based on the key name, to parse jsonThing={"foo": "quote: \""}?
No, we will declare that this value is wrapped in a char-string as
jsonThing="{\"foo\": \"quote: \\\"\"}".  Yes, this is less convenient to
type by hand, but the alternative is to have a "char-string parser" that
mixes in all the syntaxes of all the SVCB value types.  That way lies
madness.

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 5 May 2021 18:30:19 -0400

> Making it easy for millions of people entering data vs a handful of people

I have to agree with Mark here.   The majority of folks updating DNS records
are not going to be primarily DNS people, or Web folks, but random system
admins
and network engineers.

Also, the test vectors in Appendix D should be full DNS records and not
just the RDATA.
I understand this, and most of us do, but give some examples someone
looking at this can
truly copy/paste into a zone file.

But that's just me.

tim

---

From: Dick Franks <[email-masked]>
Date: Thu, 6 May 2021 16:49:51 +0100

> Yes, hence the use of "\\," for embedded commas in value-list values.

No, this is better characterised as the wound dressing covering the
bullet hole in your foot!

...

> I think that's a good description of why this arrangement was chosen.

But that is precisely what you are NOT doing.
You have assigned a special significance to the character sequence
"\\," contrary to RFC1035.

The language of RFC1035 is crystal clear that an escaped character is
parsed as plain text, independently, without regard to context, and
that any special meaning does not apply.

Strict application of the RFC1035 rules causes string   "...\\,..."
to be equivalent to "...\092,...".

BIND, NSD, and Net::DNS are all able to arrive at implementations of
SVCB using the RFC1035 standard escape conventions, which demonstrates
beyond reasonable doubt that recognising "\\," is not an essential
requirement.

Appendix A and related features should be removed from the draft.

--Dick

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 6 May 2021 11:11:01 -0700

...

> to be equivalent to "...\092,...".

I'm not sure what you're describing.  Those two inputs are universally
equivalent in zone files under the current draft.  They are both reduced to
{'\', '"'} by char-string parsing, which is applied uniformly and without
modification to all SvcParamValues.

Each SvcParamValue has its own input format.  For some SvcParamValues, '\'
and ',' may not be allowed characters.  For others, they may be ordinary
characters to be copied into the output, or they may have special
significance.

> beyond reasonable doubt that recognising "\\," is not an essential

I disagree: what you are proposing is a deviation from RFC1035 escape
conventions, and what the draft does is specifically to ensure that no such
deviation is required.  I have now encountered multiple codebases where
modifying the RFC1035 char-string parsing in the way that you suggest would
be prohibitively complex, and that complexity will only grow over time as
new SvcParamValues are defined.

The "value-list" format is a bit like a (much simpler) cousin of the SPF
macro language (https://tools.ietf.org/html/rfc7208#section-7.1).  In both
cases, the char-string decoder's output contains embedded commands that
allow the next processing stage to distinguish between delimiters (comma
and space, respectively) and escaped delimiters ("\," and "%_",
respectively).

---

From: Dick Franks <[email-masked]>
Date: Thu, 6 May 2021 21:16:54 +0100

On Thu, 6 May 2021 at 19:11, Ben Schwartz <[email-masked]> wrote:
> I'm not sure what you're describing.  Those two inputs are universally equivalent in zone files under the current draft.  They are both reduced to {'\', '"'} by char-string parsing, which is applied uniformly and without modification to all SvcParamValues.

... and the '\' without any special meaning fails to protect the comma
from the attention of the argument splitter.

> Each SvcParamValue has its own input format.  For some SvcParamValues, '\' and ',' may not be allowed characters.  For others, they may be ordinary characters to be copied into the output, or they may have special significance.
>
... and I might, or might not, have a boiled egg for breakfast!

> I disagree: what you are proposing is a deviation from RFC1035 escape conventions, and what the draft does is specifically to ensure that no such deviation is required.

I am advocating strict adherence to RFC1035 escape conventions.  You
are the one proposing to deviate.

> ...  I have now encountered multiple codebases where modifying the RFC1035 char-string parsing in the way that you suggest would be prohibitively complex, and that complexity will only grow over time as new SvcParamValues are defined.

If the development cost is prohibitive, the obvious solution is to use
BIND, NSD, or one of the other respectable implementations which are
certain to be not far behind.  If Google cannot afford the license
fee, a six line perl Net::DNS script could be used to translate
RFC1035 compliant SVCB RRs into RFC3597 format at nil cost.

>
> The "value-list" format is a bit like a (much simpler) cousin of the SPF macro language (https://tools.ietf.org/html/rfc7208#section-7.1).  In both cases, the char-string decoder's output contains embedded commands that allow the next processing stage to distinguish between delimiters (comma and space, respectively) and escaped delimiters ("\," and "%_", respectively).

That is no justification at all.   SPF people can do whatever they
like within the arguments of a TXT record.

--Dick

---

From: Tom <[email-masked]>
Date: Fri, 07 May 2021 09:57:10 +0200

Hi Dick, Ben,

I'm the (new) developer at NLNet Labs who implemented SVCB in NSD. While 
I have no strong opinion on the double escaping matter, I will pitch in 
that NSD currently adheres to the draft (as far as I'm aware).

Best,
Tom

On 2021-05-06 22:16, Dick Franks wrote:

> equivalent in zone files under the current draft.  They are both 
> reduced to {'\', '"'} by char-string parsing, which is applied 
> uniformly and without modification to all SvcParamValues.

> Each SvcParamValue has its own input format.  For some SvcParamValues, 
> '\' and ',' may not be allowed characters.  For others, they may be 
> ordinary characters to be copied into the output, or they may have 
> special significance.

> conventions, and what the draft does is specifically to ensure that no 
> such deviation is required.

> ...  I have now encountered multiple codebases where modifying the 
> RFC1035 char-string parsing in the way that you suggest would be 
> prohibitively complex, and that complexity will only grow over time as 

> The "value-list" format is a bit like a (much simpler) cousin of the 
> SPF macro language (https://tools.ietf.org/html/rfc7208#section-7.1).  
> In both cases, the char-string decoder's output contains embedded 
> commands that allow the next processing stage to distinguish between 
> delimiters (comma and space, respectively) and escaped delimiters ("\," 
> and "%_", respectively).

--Dick

---

From: Pieter Lexis <[email-masked]>
Date: Fri, 7 May 2021 12:21:10 +0200

Hi folks,

On 5/6/21 10:16 PM, Dick Franks wrote:
>> ...  I have now encountered multiple codebases where modifying the RFC1035 char-string parsing in the way that you suggest would be prohibitively complex, and that complexity will only grow over time as new SvcParamValues are defined.>
, respectively).
> [...]

For PowerDNS, we treat the parsing of SVCParams as a two-step process.
First we use the normal rfc1035 character decoder on the full SVCParam
value, after which we apply the value-list parser. The former parses
'foo\\,bar' into 'foo\,bar' that is then parsed to a list of length 1
with value {'foo,bar'}. So nothing changes from the perspective of the
rfc 1035 parser.

I can see how this might be confusing to those writing zone contents and
would support a solution that either prohibits comma's in SVCParam list
values or a different value separator that is not allowed to be embedded
in values.

Regards,

Pieter
-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com

---

From: Dick Franks <[email-masked]>
Date: Fri, 7 May 2021 14:18:25 +0100

On Fri, 7 May 2021 at 11:21, Pieter Lexis <[email-masked]> wrote:
>8

Tim W. pointed out earlier in this thread that "those writing zone
contents" are the majority stakeholders and rarely familiar with the
finer points of DNS.
If we are inflicting confusion on these people by departing from
standard and well-understood character escapes for no other reason
than the convenience of developers, then we have our priorities
seriously wrong.

--Dick

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 7 May 2021 10:02:50 -0400

I was rethinking my initial concerns, and needed to talk it out with others.
After going back over it with folks smarter than myself, it's more obvious
to me that when the need for escaping inputs will be more of an exception.

My concern is focused not so much on implementers (sorry) but the operators
and engineers who will be the ones inserting these records into zone files.

I do however want to have the presentation format examples be full DNS
records,
and not just RDATA.   In the followinbg section in on failure cases, DNS
records
are used:

example.com.   SVCB   1 foo.example.com. mandatory

The test vectors should be the same.

tim

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 7 May 2021 15:52:09 +0000

> values or a different value separator that is not allowed to be embedded

Pieter has a point here: to parse correctly, you need a two-step (or two-level) process. The *only* way to prevent that in the spec would be to say that commas are forbidden in  parameter values. However, even if the spec said that, someone would mess up and put a comma in a parameter value, and then different parsers will yield different values based on whether or not they took that shortcut.

Escaping is hard.

--Paul Hoffman

---

From: Dick Franks <[email-masked]>
Date: Sun, 9 May 2021 13:01:30 +0100

> > with value {'foo,bar'}. So nothing changes from the perspective of the

Pre-processing of '\\,' into the RFC1035 standard '\,' is
superficially attractive, but also fraught with danger.

A parser could have some fun with this one:

    $ORIGIN example.com
    @   SVCB   1 foo
key6="\032\001\013\184\000\000\000\000\000\000\000\000\\\\,\000"
    ; a.k.a.   ipv6hint=2001:db8::5c5c:2c00

> Pieter has a point here: to parse correctly, you need a two-step (or two-level) process. The *only* way to prevent that in the spec would be to say that commas are forbidden in  parameter values. H…

Undeniably.

The spec only needs to say that a comma needs to be escaped  ( \, ) in
order to be disregarded as a separator.

BIND, NSD, Net::DNS, and PowerDNS can all do this, so there is little
mileage in claiming that it is not possible.

The "impossible" can be made possible by doing the right things in the
correct order.
Selecting the right things and the correct order is left as an
exercise for the student.

--Dick

---

From: Paul Wouters <[email-masked]>
Date: Sun, 9 May 2021 14:26:21 -0400

>    ; a.k.a.   ipv6hint=2001:db8::5c5c:2c00

This is all pretty terrible. I agree with Tim that we should not inflict this onto the users. Or perhaps we can already pre-allocate some CVE numbers for the security issues this will generate.

Keep the record simple, we are not going for Turing complete here. I recommend to authors take this discussion as advise to improve / simplify this aspect of the draft.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 9 May 2021 23:26:41 +0000

> Keep the record simple, we are not going for Turing complete here. I recommend to authors take this discussion as advise to improve / simplify this aspect of the draft.

I don't think this request is actually doable. The requirements for the SVCB Rdata are:
1. Must be entered by the zone operator as ASCII text (not all a jumble of hex values)
2. Is a list of key/value pairs
3. Values are likely to be a list of items

Given these three things, it seems that there will *always* be an escaping problem for the item delimiter in #3. In the current draft, the item delimiter is a comma, so there has to be a way to escape a comma that is in an item. Few types of items would ever need a comma in their values. If a different character is chosen for the item delimiter, it too will need to be escaped.

If I'm wrong about this being as good as it can be, there must be an item delimiter that is better than a comma. I am not thinking creatively enough to figure out what might be better than a comma. I'd be happy to hear proposals for a better item delimiter. 

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Sun, 9 May 2021 19:42:30 -0400

> If I'm wrong about this being as good as it can be, there must be an item delimiter that is better than a comma. I am not thinking creatively enough to figure out what might be better than a comma.…

I am quite behind on this topic, but I presume there's a reason to put all these key-value pairs in a list in one RR?

If we compare the two fictional RRTypes EG1 and EG2 illustrated below:

example.com. EG1 key1=value1,key2=value2,...

example.com. EG2 key1 value1
example.com. EG2 key2 value2

It seems to me that EG2 avoids the need for delimiters at all. There's a bit of overhead resulting from the need for a larger RRSet but it's not obvious that that's a problem. 

If the SvcParams field of the SVCB RR was a domain name rather than an explicit list this would all look a lot more DNS-like as far as parsing goes. This would also allow a single set of SvcParams key-value pairs to be included in different service bindings without having to be sent each time or to be bound to something provided a service provider (SVB in customer.org zone that refers to SvcParams.provider.com) giving the provider some ability to maintain some aspects of the service).

Perhaps this horse has already sailed but I thought I'd mention it. 

Joe

---

From: Dick Franks <[email-masked]>
Date: Mon, 10 May 2021 10:22:07 +0100

> It seems to me that EG2 avoids the need for delimiters at all. There's a bit of overhead resulting from the need for a larger RRSet but it's not obvious that that's a problem.

The current draft can reach the finishing line without tearing it to pieces.

> Perhaps this horse has already sailed but I thought I'd mention it.

Perhaps this horse needs to be tested for banned substances!

--Dick

---

From: Pieter Lexis <[email-masked]>
Date: Mon, 10 May 2021 11:42:23 +0200

Hi Dick,

>     ; a.k.a.   ipv6hint=2001:db8::5c5c:2c00

A zone owner/editor would never even think of typing in IP addresses
like that. And no decoder should ever write that out (and if it does,
would a zone-owner read it?). Also, when using the generic format, the
full value should be the 'wire' format so there's comma delimiter
between values. For ALPN you'd have [value1 len][value 1][value2
len][value2] and for key6 [encoded first ipv6 address bytes][encoded
second ipv6 address bytes].

>From what I gather, this is the case? With the caveat that there is a
2-step process for parsing the values for keys defined as paramlists.

Cheers,

Pieter

---

From: Joe Abley <[email-masked]>
Date: Mon, 10 May 2021 06:08:25 -0400

On May 10, 2021, at 05:42, Pieter Lexis <[email-masked]> wrote:

> like that.

Right, but an attacker who wants to take advantage of the impact of that observation in the construction of some parser might, which is why it's a security concern. 

Joe

---

From: Dick Franks <[email-masked]>
Date: Mon, 10 May 2021 12:02:12 +0100

> 3. Values are likely to be a list of items

It is very much doable.
BIND, NSD, and PowerDNS can already parse values containing '\,'
escapes, and each of these has a substantial installed base.

My objections can be entirely satisfied by modest changes to reconcile
the document with RFC1035.

> If I'm wrong about this being as good as it can be, there must be an item delimiter that is better than a comma. I am not thinking creatively enough to figure out what might be better than a comma.…

My objection is narrowly focussed on the escape mechanism, nothing
more.  Changing the delimiter is neither necessary nor relevant.

I am happy to contribute the necessary words.

--Dick

---

From: Pieter Lexis <[email-masked]>
Date: Mon, 10 May 2021 16:43:29 +0200

Hi Dick,

> I am happy to contribute the necessary words.

If you have the words to fix this issue that would need to changes the
code but clears everything up, do it :).

Cheers,

Pieter

---

From: Pieter Lexis <[email-masked]>
Date: Mon, 10 May 2021 17:23:03 +0200

Hi Joe,

On 5/10/21 1:42 AM, Joe Abley wrote:
> It seems to me that EG2 avoids the need for delimiters at all. There's a bit of overhead resulting from the need for a larger RRSet but it's not obvious that that's a proble>

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.

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.

Cheers,

Pieter

---

From: Joe Abley <[email-masked]>
Date: Mon, 10 May 2021 11:35:13 -0400

Hi Pieter,

> data from all matched rrsets, whereas now you get all that data in one

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.

> 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

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 10 May 2021 09:56:37 -0700

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 <[email-masked]> wrote:

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 10 May 2021 13:12:53 -0400

Hi Ben,

On 10 May 2021, at 12:56, Ben Schwartz <[email-masked]> wrote:

> I don't support breaking the SvcParams into separate RRs across the RRSet.  This would be an extremely inefficient encoding in wire format,

I think that assertion may well be worth challenging, and...

> and would conflict with the usual understanding of resource records as independently meaningful alternatives.

... I think we disagree about how we usually interpret the use of RRSets with more than one member RR.

>  It would also require a dramatic rewrite of a specification that is now widely deployed.

However, this seems clear (see my earlier horse/sailed comment). Given that the draft semantics of SVCB have already seen some implementation, any new semantics would need a new RRType (SVCC? :-)

I admit I have a certain aesthetic bias here since I find the entire concept of embedding a list of parameters inside a single RR to be very un-DNS-like. However, I found Mr Wouter's concerns (paraphrasing, "perhaps we should pre-allocate a set of CVE numbers for this") worth considering, and would hope that if there is a reason to burn the current RRType on security grounds (or any grounds more compelling than aesthetic) that we would do so.

Joe

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 10 May 2021 21:14:18 +0200

> code but clears everything up, do it :).

I would like to clarify that Pieter meant 'need no changes to the code'.

:-)
 
Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 May 2021 16:04:21 -0400 (EDT)

> Right, but an attacker who wants to take advantage of the impact of that observation in the construction of some parser might, which is why it's a security concern.

Some DN / RDN / CN parsing tools have hthis issue too and some allow a
comma with an additional masking comma, eg  OU=testing,,security, O=Mayhem

Then other code can just never ever allow masking, double masking,
backslshing, single or double quotes or what not.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 May 2021 17:37:49 -0400 (EDT)

> It would also require a dramatic rewrite of a specification that is now widely deployed.

The IETF is not a rubber-stamp factory for corporate proposals though.

The tendency for corporation to bring up something at the IETF that is
"too far gone" for modifications during the IETF process as a trend
is worrying, and does make me personally feel less sympathetic towards
those kind of deployments.

Did you reach out to SecDir for an early review request? I cannot find
anything in the SecDir archives related to HTTPSVC or SVCB.

DNS records have been using _prefix labels for a while now to split up
RR information to be more specific related to targetted DNS requests.
This RR type is unfortunately not using that, and thus the complexity
and securtity issues are popping up now.

> 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

Or to simply disable all JSON/COBR/UTF-16 et all ? Do we really need
emoticons in our transport definitions ?

> 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

If that is the main argument, what's wrong with plain ascii limitations?

Anyway, I think this issue deserves a full discussion, without taking
into account the current wide deployment. Also bacause everything out
there that does not support SVCB also continues to work, so it is not
the end of the world if SVCB needs to go through some changes. But
as Mr.Abley said (and I paraphrase) "we can burn an RR type allocation
easilly".

Paul

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 May 2021 08:13:58 +1000

> On 11 May 2021, at 02:56, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 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):
> 3. Feed this parser characters from the zone file until it declares completion or error
> 
> 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.

Yet you fail to mention that the following

3. Encoding
   
   JSON text SHALL be encoded in Unicode.  The default encoding is
   UTF-8.

The UTF-16 JSON strings values are encoded as UTF-8.  UTF-8 in zone files usually ends up being \DDD for non-ASCII and ASCII control octets once it has gone from text -> wire -> text to put everything into ASCII printable.  Zone files are ASCII documents.  If you are using the values in other contexts you may convert the
wire forms differently.

> 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

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 10 May 2021 15:38:11 -0700

...

> > 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
> The UTF-16 JSON strings values are encoded as UTF-8.  UTF-8 in zone files
> usually ends up being \DDD for non-ASCII and ASCII control octets once it
> has gone from text -> wire -> text to put everything into ASCII printable.
> Zone files are ASCII documents.  If you are using the values in other
> contexts you may convert the
> wire forms differently.
>

It sounds like you're saying that \DDD escape processing would happen
entirely before JSON parsing.  That would be a two-pass design, just like
what the current draft says.  Consider a json value of {"a":"\\123"} (two
'\' due to escaping within a JSON string).  It sounds like, in your plan,
this would be escaped to something like jsonKey={"a":"\092\092123"}, or
perhaps jsonKey={"a":"\\\\123"}.  Those are both valid in the current SVCB
draft.

I think your solution here is exactly what is proposed in the current SVCB
draft, so I fully support it.  However, it necessarily results in
double-escaping, which is the initial concern raised in this thread.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 May 2021 22:46:23 +0000

On May 10, 2021, at 9:56 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 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.  

Fully agree. It is a large change in the DNS protocol for a receiver to have to internally group multiple RRs based on matching (priorty | target) tuples and make security decisions based on the group, not on the record.

> It would also require a dramatic rewrite of a specification that is now widely deployed.

Er, screw that. The fact that some developers deployed this even though it hadn't even completed WG last call, much less had a wider IETF review, is a problem for those developers to solve.

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

This is central to the problem of SVCB: it is more complex than traditional DNS RRtypes, and different developers have different views of what would make it simpler for them to implement and/or simpler for zone operators to type into zone files.

I hope Dick's proposed simple addition is useful. I'm not a developer, and I don't write into zones very often, but I suspect that "it's all in one record that has an addition to the parsing" will be easier and safer to implement than "the receiver has to handle groups of records in a new way".

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 May 2021 00:12:10 +0100

Hiya,

Without commenting on the rest of the discussion (though
I do agree with those who made the point that optimising
for those writing zone files here is better than for
those parsing zone files)...

On 10/05/2021 17:56, Ben Schwartz wrote:
> It would also require a dramatic rewrite of a

I'm not aware this is widely deployed. To be fair I mostly
care about deployments that support ECH and so far I know
of 2 of those. There may be more doing HTTPS or SVCB but
not ECH I guess. If so, I'd find it valuable to see a list
of those so I can get a sense of the variability to be
seen in HTTPS/SVCB deployments.

So - can you provide some backup for that claim of being
widely deployed that might help me see how folks are choosing
to deploy?

Thanks,
S.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 May 2021 09:14:25 +1000

> On 11 May 2021, at 08:46, Paul Hoffman <[email-masked]> wrote:
> 

Actually, the process problem is that record format keeps changing AFTER the code point has been assigned and the record format THEORETICALLY been FIXED.  When you go down the template route for code point assignment that FIXES
the wire and presentation formats.

A. Submission Date:  2020-06-18

B.1 Submission Type:  [ X ] New RRTYPE  [ ] Modification to RRTYPE
B.2 Kind of RR:  [ X ] Data RR  [ ] Meta-RR

C. Contact Information for submitter (will be publicly posted):
   Name: Erik Nygren
   Email Address: erik+ietf&nygren.org
   International telephone number:  +1 617 444 3938
   Other contact handles:

D. Motivation for the new RRTYPE application.
   Please keep this part at a high level to inform the Expert and
   reviewers about uses of the RRTYPE.  Most reviewers will be DNS
   experts that may have limited knowledge of your application space.

   The "HTTPS" DNS RR type facilitates the lookup of information
   needed to make connections for origin resources, such as for HTTPS
   URLs.  HTTPS RRs allow an origin to be served from multiple network
   locations, 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.  By providing more information to the
   client before it attempts to establish a connection, these records
   offer potential benefits to both performance and privacy.
   For example, the presence of an HTTPS RR indicates that clients
   should upgrade insecure "http" URLs to secure "https" URLs prior
   to establishing a connection.

E. Description of the proposed RR type.
   This description can be provided in-line in the template, as an
   attachment, or with a publicly available URL.

   See https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00
   
F. What existing RRTYPE or RRTYPEs come closest to filling that need
   and why are they unsatisfactory?

   (from I-D.draft-ietf-dnsop-svcb-https-00 #appendix-A)

   The SRV record [RFC2782] can perform a similar function to the SVCB
   record, informing a client to look in a different location for a
   service.  However, there are several differences:
   o  SRV records are typically mandatory, whereas clients will always
      continue to function correctly without making use of HTTPS RRs.
   o  SRV records cannot instruct the client to switch or upgrade
      protocols, whereas HTTPS RRs can signal such an upgrade (e.g.. to
      HTTP/2).
   o  SRV records are not extensible, whereas HTTPS RRs can be
      extended with new parameters, such as for
      TLS Encrypted Client Hello keys.

G. What mnemonic is requested for the new RRTYPE (optional)?

   HTTPS

H. Does the requested RRTYPE make use of any existing IANA registry
   or require the creation of a new IANA subregistry in DNS
   Parameters?  If so, please indicate which registry is to be used
   or created.  If a new subregistry is needed, specify the
   allocation policy for it and its initial contents.  Also include
   what the modification procedures will be.

   Yes, per I-D.draft-ietf-dnsop-svcb-https-00#section-12:

   * Create a new "Service Binding (SVCB) Parameter Registry"
     with an initial population of entries.  This would
     be shared with the SVCB RR type.
   * Add an _https entry to the  DNS Underscore
     Global Scoped Entry Registry.

I. Does the proposal require/expect any changes in DNS
   servers/resolvers that prevent the new type from being processed
   as an unknown RRTYPE (see [RFC3597])?

   No.  While DNS servers and resolvers may perform performance
   optimizations described in the I-D, these are optional
   and do not preclude processing as an unknown RRTYPE.

J. Comments:

   The plan is to bring draft-ietf-dnsop-svcb-https to Working Group
   Last Call during Summer 2020.  A early code point allocation
   for the SVCB RRtype and HTTPS RRtype is requested to enable interop
   testing between multiple implementations that are in-progress.

> --Paul Hoffman_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 10 May 2021 23:20:37 +0000

On May 10, 2021, at 4:14 PM, Mark Andrews <[email-masked]> wrote:
> Actually, the process problem is that record format keeps changing AFTER the code point has been assigned and the record format THEORETICALLY been FIXED.

Mark makes an excellent point, one that people in the DNS world routinely forget. 

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Mon, 10 May 2021 16:59:04 -0700

On Mon, May 10, 2021 at 9:58 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> 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.
>
> [snip]

> 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

[snip]

Let me ask what is probably a really leading question, in terms of the
semantics for SVCB (and HTTPS).
If I understand the draft in its current form, the goal is to be able to
encode and parse some DNS RRset in such a way as it lets you obtain, in one
fell swoop (but possibly multiple passes for parsing) everything needed to
obtain:
- A well-ordered list of one or more targets, where each target has a set
of attributes.
- The examples currently show RRsets with multiple distinct Priority values
- However, the words indicate that it is permissible for two RRs in the set
to have the same Priority value.
- The effect is having an array of objects, each of which has a priority,
name, and optional set of key/value pairs (where values can be lists).

So, I have a proposed solution that will make the parsing, and generation
of post-parsing JSON objects as close to trivial as possible.
This borrows heavily from what Joe Abley already wrote. I'm just taking the
concept to its (il)logical conclusion.

Encode everything using the following mechanism:
Priority Enumeration Key Value
One of the "Keys" would be Target, with a corresponding Value of FQDN.
All of the records with the same value for "enumeration" belong together,
and form a single SvcParameter list.
For the AliasForm, both the Priority and Enumeration would be 0, and only a
single Target,Value pair are permitted.

To take one example from the draft, and re-encode it thusly:
 $ORIGIN svc.example. ; A hosting provider.
pool  7200 IN HTTPS 1 h3pool alpn=h2,h3 ech="123..."
              HTTPS 2 .      alpn=h2 ech="abc..."
pool   300 IN A        192.0.2.2
              AAAA     2001:db8::2
h3pool 300 IN A        192.0.2.3
              AAAA     2001:db8::3

This would become (for brevity, encoding just a list of RDATA values for
all of the "pool HTTPS" records):
1 1 target "h3pool"
1 1 alpn "h2,h3"
1 1 ech "123..."
2 2 target "."
2 2 alpn "h2"
2 2 ech "abc..."

I think this is likely a lot easier to parse, and to convert into whatever
form your ALPN-handling stuff wants (including JSON).
I is also very close to trivial to write a JSON -> Zone File
transliterator, so user input in JSON (which meets the JSON structure
expected) can be handled, and even bidirectionally allow Zone File -> JSON
for user editing of already-existent entries.

For the example above;
If the priority of both of the above were the same, they would be all "1 1
..." and "1 2 ..." instead of "1 1 ..." and "2 2 ...".
If my JSON isn't horribly bad, I think this would get converted into:
 [ { "name" : "h3pool", "priority" : 1, "SvcParams" : { "alpn" : "h2,h3",
"ech" : "123..." } }, ...]

IMNSHO, it'll be faster to discard any existing parsing code, and embrace
this as the Zone File format (and wire format) going forward.

Hope this is helpful to the discussion.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 May 2021 10:44:57 +1000

> On 11 May 2021, at 09:20, Paul Hoffman <[email-masked]> wrote:
> 

Just for reference ZONEMD switched two fields between draft-wessels-dns-zone-digest-05.txt and
RFC 8976.  "Digest Type | Reserved” -> "Scheme | Hash Algorithm”.  This resulted in BIND rejecting
zones with ZONEMD records using SHA-512 digests (digest field has the wrong length for Digest Type 1).
Renaming fields is fine.  Reordering/repurposing non reserved isn’t as it breaks stuff.  Now we are
making BIND compatible with RFC 8976 but we should never have been put in this position.

---

From: "libor.peltan" <[email-masked]>
Date: Tue, 11 May 2021 12:30:37 +0200

Hi all,

this is actually not the first time someone has come with this issue: 
https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1&index=WxZLxeJF3vSHiOG0jGm8kek5ajI

If there really is a strong reason for putting multiple key-value 
records into one RData (instead of one RRSet), it should be described 
somewhere clearly (more clearly than Ben's two pretty relativisable 
sentences). If so, I would accept it happily.

Brian, thanks for nice elaborate on the "counter-proposal". What exactly 
is illogical on that, in the end?

FYI in Knot DNS authoritative, we were able to implement 
zonefile<->wireformat transitions according current draft (being a Merge 
request to date). I feel no need to change the escaping manner.

Libor

Dne 11. 05. 21 v 1:59 Brian Dickson napsal(a):
>
>
> On Mon, May 10, 2021 at 9:58 AM Ben Schwartz 
> <bemasc=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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.
>
> [snip]
>
>     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.
>
>
> [snip]
>
> If I understand the draft in its current form, the goal is to be able 
> to encode and parse some DNS RRset in such a way as it lets you 
> obtain, in one fell swoop (but possibly multiple passes for parsing) 
> everything needed to obtain:
> - A well-ordered list of one or more targets, where each target has a 
> set of attributes.
> - However, the words indicate that it is permissible for two RRs in 
> the set to have the same Priority value.
> - The effect is having an array of objects, each of which has a 
> priority, name, and optional set of key/value pairs (where values can 
> be lists).
>
> So, I have a proposed solution that will make the parsing, and 
> generation of post-parsing JSON objects as close to trivial as possible.
> This borrows heavily from what Joe Abley already wrote. I'm just 
> taking the concept to its (il)logical conclusion.
>
> All of the records with the same value for "enumeration" belong 
> together, and form a single SvcParameter list.
> For the AliasForm, both the Priority and Enumeration would be 0, and 
> only a single Target,Value pair are permitted.
>
> This would become (for brevity, encoding just a list of RDATA values 
> for all of the "pool HTTPS" records):
> 1 1 target "h3pool"
> 1 1 alpn "h2,h3"
> 1 1 ech "123..."
> 2 2 target "."
> 2 2 alpn "h2"
> 2 2 ech "abc..."
>
>
> I think this is likely a lot easier to parse, and to convert into 
> whatever form your ALPN-handling stuff wants (including JSON).
> expected) can be handled, and even bidirectionally allow Zone File -> 
> JSON for user editing of already-existent entries.
>
> For the example above;
> If the priority of both of the above were the same, they would be all 
> "1 1 ..." and "1 2 ..." instead of "1 1 ..." and "2 2 ...".
>  [ { "name" : "h3pool", "priority" : 1, "SvcParams" : { "alpn" : 
> "h2,h3", "ech" : "123..." } }, ...]
>
> IMNSHO, it'll be faster to discard any existing parsing code, and 
> embrace this as the Zone File format (and wire format) going forward.
>

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 11 May 2021 13:08:48 +0200

> embrace this as the Zone File format (and wire format) going forward.

I think that would imply burning the currently allocated RRtype code 
pair and requesting a new pair from IANA.  Not unthinkable, but somewhat 
costly; just noting.  I'm not even 100% sure whether we could really 
reuse the allocated "SVCB" and "HTTPS" names if their wire-format changes.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 May 2021 09:08:08 -0700

On Tue, May 11, 2021 at 3:31 AM libor.peltan <[email-masked]> wrote:

> If there really is a strong reason for putting multiple key-value records
> into one RData (instead of one RRSet), it should be described somewhere
> clearly
>
OK, I've proposed text documenting the reasoning here:
https://github.com/MikeBishop/dns-alt-svc/pull/323/files.

The proposed text is:

Storing a key-value map within a single RR, rather than placing each
key-value
pair in a separate RR, provides the following advantages:

* It enables a familiar key=value zone file syntax that matches zone
authors'
  experience with command-line arguments and other typical key-value
mappings.
* It avoids requiring zone file authors to manage inter-pair binding IDs.
* It makes each record independently meaningful, consistent with the usual
  convention for DNS records (c.f. SRV, MX, AAAA, etc.).
* It saves at least 11 bytes of overhead per parameter by avoiding
repetition of
  the name, type, class, TTL, and inter-pair binding ID.
* It provides a wire format whose structural nesting matches the logical
scope
  of each key=value pair, and avoids requiring cross-RR reconstruction of
  bindings by the client.

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 11 May 2021 16:16:12 +0000

> On May 10, 2021, at 5:44 PM, Mark Andrews <[email-masked]> wrote:
> 
> 

Mark,

Thank you for quickly making this change in BIND.  You are correct that
the case of ZONEMD the interpretation of fields did change, although the
wire format did not.

You've made the point a few times that code point allocation freezes the
record format (not just in wire format but also presentation and meaning).
When I went through the RR type allocation process this was not evident
to me.  Is this (theoretical?) "policy" written down somewhere?  RFC 6895
doesn't seem to say anything like that.

DW

---

From: Joe Abley <[email-masked]>
Date: Tue, 11 May 2021 12:19:59 -0400

Hi Ben,

On 11 May 2021, at 12:08, Ben Schwartz <bemasc=[email-masked]> wrote:

> OK, I've proposed text documenting the reasoning here: https://github.com/MikeBishop/dns-alt-svc/pull/323/files <https://github.com/MikeBishop/dns-alt-svc/pull/323/files>.

I definitely appreciate the effort, since I think I agree that documenting the design decisions are a good idea. However, I think perhaps the reasoning needs more work (see below).

> The proposed text is:
> 
> Storing a key-value map within a single RR, rather than placing each key-value
> * It enables a familiar key=value zone file syntax that matches zone authors'
>   experience with command-line arguments and other typical key-value mappings.

Since zone files generally don't include any key value pairs of the kind SVCB currently specifies, I don't understand this point. Surely the unfamiliarity with how to parse this kind of syntax illustrates that this is not familiar?

> * It avoids requiring zone file authors to manage inter-pair binding IDs.

I think you will have to expand that point, since I'm not convinced I understand what you mean.

>   convention for DNS records (c.f. SRV, MX, AAAA, etc.).

If you think of the DNS itself as a key-value store, with keys of the form (QCLASS, QTYPE, QNAME) then the corresponding value is an RRSet, not an individual resource record. Individual RRs are not returned in responses; RRSets are (understanding that the results are not functionally different in the case of an RRSet with a single member).

Your examples of SRV, MX and AAAA, somewhat ironically, are all prime examples of why the whole RRSet matters and you can't rely on a single RR from a set in a respose.

> * It saves at least 11 bytes of overhead per parameter by avoiding repetition of

... but it inflates response volume in the case where a separate SvcParams RRSet is able to be cached significantly longer than the SVCB RRSet.

> * It provides a wire format whose structural nesting matches the logical scope

This seems like it is documenting a design choice rather than explaining it. The decision to include a list of key-value pairs in the SVCB RDATA is good because it avoids having to do something different?

Joe

---

From: "libor.peltan" <[email-masked]>
Date: Tue, 11 May 2021 18:26:59 +0200

Hi Ben,

Dne 11. 05. 21 v 18:08 Ben Schwartz napsal(a):
>
>
> On Tue, May 11, 2021 at 3:31 AM libor.peltan <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     records into one RData (instead of one RRSet), it should be
>     described somewhere clearly
>
> https://github.com/MikeBishop/dns-alt-svc/pull/323/files 
> <https://github.com/MikeBishop/dns-alt-svc/pull/323/files>.
>
> The proposed text is:
Thank you for at least this effort.
>   the name, type, class, TTL, and inter-pair binding ID.

May I be wrong, but I think that name, type, class and TTL are not 
repeated in one RRSet with multiple RData. Not in wire format and not 
necessarily even in zonefile. (?)

The inter-pair binding ID would be not too large, maybe it would cancel 
out with some avoided textual dash :)

Libor

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 May 2021 09:32:20 -0700

> On 11 May 2021, at 12:08, Ben Schwartz <bemasc=[email-masked]>
..

> ... but it inflates response volume in the case where a separate SvcParams
> RRSet is able to be cached significantly longer than the SVCB RRSet.
>

It sounds like you're proposing a design in which the information in one
SVCB record is not just spread across multiple records in an RRSet, but
actually across multiple RRSets.  That is not just a variation on SVCB, but
an entirely different proposal.

> This seems like it is documenting a design choice rather than explaining
> it. The decision to include a list of key-value pairs in the SVCB RDATA is
> good because it avoids having to do something different?
>

To restate this sentence, it is good because the concrete syntactical
structure matches the abstract conceptual structure, and (relatedly)
because it simplifies client implementation.

---

From: Dick Franks <[email-masked]>
Date: Tue, 11 May 2021 17:40:09 +0100

All,

As part of a side discussion, I was admonished for my rather flippant
approach to a significant security issue and failure to explain
clearly how it manifests itself..

>     ; a.k.a.   ipv6hint=2001:db8::5c5c:2c00

Although a few sharp-eyed people recognised the security implications
immediately, I realise that I should have included the broken result
to illustrate the problem more clearly.

 example.com.    IN    SVCB    ( \# 38 0001     ; 1
    03666f6f076578616d706c6503636f6d 00     ; foo.example.com.
    0006 000f 20010db800000000000000005c2c00 )

instead of the expected:

 example.com.    IN    SVCB    ( \# 39 0001     ; 1
    03666f6f076578616d706c6503636f6d 00     ; foo.example.com.
    0006 0010 20010db800000000000000005c5c2c00 )

Observe that the IPv6 address is shortened to 15 octets.

(Note these results were produced by my development Net::DNS and may
not be repeatable with the latest published version 1.31)

--Dick

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 May 2021 10:04:58 -0700

> Observe that the IPv6 address is shortened to 15 octets.

I'm not sure what the concern is here, but Section 2.1 of the current draft
[1], which specifies the parsing behavior in this case, simply says that
the value in this form is a char-string.  There is no mention of commas
anywhere in that section, so any special handling of commas is clearly
incorrect.  (Previous versions of the draft have long specified the same
behavior, with only editorial adjustments.)

[1]
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html#name-zone-file-presentation-form

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 May 2021 10:13:40 -0700

On Tue, May 11, 2021 at 10:04 AM Ben Schwartz <[email-masked]> wrote:

>
> There is no mention of commas anywhere in that section
>

My apologies, there is a mention of commas later in the section, as
guidance for standards development of future key types.  If this is a
source of confusion, we can remove or relocate it.

---

From: Joe Abley <[email-masked]>
Date: Tue, 11 May 2021 13:32:52 -0400

On 11 May 2021, at 12:32, Ben Schwartz <[email-masked]> wrote:

> It sounds like you're proposing a design in which the information in one SVCB record is not just spread across multiple records in an RRSet, but actually across multiple RRSets.

Yes, that's what I tried to sketch out before. The SvcParams in an SVCB RR becomes a pointer to a second RRSet with a different RRType. So the SvcParams information is spread across multiple records in a a different RRSet from the SVCB RRRSet. If it's still not clear what I mean, I can try again.

Note that I'm not proposing a change to the spec, just illustrating that different design choices were possible that avoid the need for delimiters or escaping.

While we're on the topic of RRSets and multiple RRTypes, the way that AliasMode and ServiceMode are distinguished is also a bit clunky; what are the implications of needing to remove all ServiceMode RRs in an RRSet in the event that one of them is found to be in AliasMode if we imagine that some consumers of these responses will get it wrong? Was there any thought given to an RR schema that prevented such ambiguities from being published?

>  That is not just a variation on SVCB, but an entirely different proposal.

I'm not sure how you think of those two things as different. Isn't every variation of something a new something?

> To restate this sentence, it is good because the concrete syntactical structure matches the abstract conceptual structure, and (relatedly) because it simplifies client implementation.

What are the concrete syntactical structure and the abstract conceptual structures? If those are terms of art I apologise; I'm not familiar with them.

What are you comparing the client implementation to in your final comment? What other design option was found to be more complex to implement on the client side?

I'm sure it feels frustrating to get all these questions at the last minute, and I apologise (as I think I said before) that I did not follow this work more closely, earlier.

Joe

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 May 2021 11:12:02 -0700

On Tue, May 11, 2021 at 10:32 AM Joe Abley <[email-masked]> wrote:

> > ... but it inflates response volume in the case where a separate
> SvcParams RRSet is able to be cached significantly longer than the SVCB
> RRSet.
> >
> actually across multiple RRSets.
>
> Yes, that's what I tried to sketch out before. The SvcParams in an SVCB RR
> becomes a pointer to a second RRSet with a different RRType. So the
> SvcParams information is spread across multiple records in a a different
> RRSet from the SVCB RRRSet. If it's still not clear what I mean, I can try
> again.
>
> Note that I'm not proposing a change to the spec, just illustrating that
> different design choices were possible that avoid the need for delimiters
> or escaping.
>

OK, thanks for helping me understand your thought process.

> While we're on the topic of RRSets and multiple RRTypes, the way that
> AliasMode and ServiceMode are distinguished is also a bit clunky; what are
> the implications of needing to remove all ServiceMode RRs in an RRSet in
> the event that one of them is found to be in AliasMode if we imagine that
> some consumers of these responses will get it wrong?

I think the recipient logic ("if there is an AliasMode record, just use
it") is simple, and not likely to be a source of confusion.  Given that
publishers SHOULD NOT publish mixed-mode RRSets, both sides would have to
be misbehaving for such a bug to be triggered.  If both sides are
noncompliant, presumably the recipient would attempt to connect using one
or more of the ServiceMode records, and succeed if they are usable.  This
doesn't seem problematic to me.  The purpose of this exclusion was mainly
to simplify analysis, avoid inefficient configurations, and maintain
parallelism with CNAME.

> Was there any thought given to an RR schema that prevented such
> ambiguities from being published?
>

This design choice, like many aspects of SVCB, was constrained by latency
and efficiency considerations.  However, note that the ambiguity is
limited: SvcPriority zero sorts to the top, so clients will naturally see
it first.

> variation of something a new something?

I think the distinction might be useful as a matter of working group
process.

> >> This seems like it is documenting a design choice rather than
> explaining it. The decision to include a list of key-value pairs in the
> SVCB RDATA is good because it avoids having to do something different?
> >
> What are the concrete syntactical structure and the abstract conceptual
> structures? If those are terms of art I apologise; I'm not familiar with
> them.
>

The concrete wire-format syntax is an octet sequence containing a
TargetName and some SvcParam key-value pairs.

The abstract structure is a "binding" comprising a TargetName and a
key-value map that is associated with that TargetName.

What are you comparing the client implementation to in your final comment?
> What other design option was found to be more complex to implement on the
> client side?
>

I was comparing it to designs where the TargetName and params are separated
into different RRs, or mixed into an RRSet with other bindings.  In such
designs, the client must perform additional work to fetch, associate, or
reconstruct these different components that are encoded or delivered
separately but are only usable as a unit.

I'm sure it feels frustrating to get all these questions at the last
> minute, and I apologise (as I think I said before) that I did not follow
> this work more closely, earlier.
>
>
> Joe
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 May 2021 05:49:11 +1000

While it is not written down that it is frozen you are required to give enough information to implement it with the expectation that it will be implemented by multiple vendors. 

Once implemented you then have to deal with backwards compatibility with existing implementations if changes are made.

Mixing I-D/RFC and template mechanisms for assigning and publishing type points is fraught with danger as you then run into issues we have been seeing here.  You actually thought about making ZONEMD future proof which was good and should have provided enough flexibility.  
-- 
Mark Andrews

> On 12 May 2021, at 02:16, Wessels, Duane <[email-masked]> wrote:
> 
> 
>

---

From: Brian Dickson <[email-masked]>
Date: Tue, 11 May 2021 14:30:37 -0700

On Tue, May 11, 2021 at 11:12 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

>> > It sounds like you're proposing a design in which the information in
>> one SVCB record is not just spread across multiple records in an RRSet, but
>> Yes, that's what I tried to sketch out before. The SvcParams in an SVCB
>> RR becomes a pointer to a second RRSet with a different RRType. So the
> and efficiency considerations.
>

I have a question (or maybe several) about the latency issue(s)... see
below for context and the question(s).

> key-value map that is associated with that TargetName.

Also related to the latency question(s) is (are) the questions about
TargetName and associated values.... see below...

> I was comparing it to designs where the TargetName and params are
> separated into different RRs, or mixed into an RRSet with other bindings.
> In such designs, the client must perform additional work to fetch,
> associate, or reconstruct these different components that are encoded or
> delivered separately but are only usable as a unit.
>

Here's where the related questions begin (and also include the client
activities for fetching data, but also relate to publication of data being
fetched....)

I think there are design details (or maybe architecture is a better term)
on the components of the binding, and the origin of those components, that
is worth exploring in greater detail.

I'll start with what I think are the relevant entities/parties, and how
those relate to the HTTPS parts, and the DNS parts that support those (and
for which the SVCB and HTTPS records are intending to improve).

I believe the highest-level entities would be:

   - One (or more) Web hosting and/or CDN providers, which include some DNS
   components specific to the domain (the domain which is the owner name of
   the HTTPS record)
   - A DNS operator (either DNS hosting provider, or possibly the domain
   owner doing their own DNS)
   - From the perspective of a client, a DNS resolver (which may or may not
   have been upgraded to do anything special for handing of HTTPS or SVCB)
   - The client itself (web browser which is doing the appropriate queries
   including HTTPS or SVCB)

If I understand things correctly, each Web hosting or CDN provider would
supply the appropriate (corresponding) SvcParameters that are associated
with the particular TargetName to the domain owner.
Another way to put it is, the SvcParameters are actually bound to the
TargetName, not the owner name of the HTTPS record, and the Web/CDN
provider is (semantically speaking, not DNS-speaking) "authoritative" for
those parameters.

Is this accurate?

So, the binding (of TargetName to SvcParams) is the thing that optimizes
the HTTPS connections (e.g. H2/H3 etc),
And, the placement of the binding parameters at the DNS record that
references the TargetName, is an optimization to reduce DNS lookup latency.

In the current design, the domain owner needs to, in effect, do a
copy/paste from each Web/CDN providers' information into the domain owner's
own DNS zone, including the TargetName and SvcParameters.
The domain owner then would assign Priority values to each such record,
thus prioritizing and/or balancing records provided by multiple Web/CDN
providers.

There is a potential for errors to be produced when the domain owner does
this copy/paste.
And the issue of managing any expansion of key,value pairs as different
records in the RRset is the result of the copy/paste mechanism (i.e.
copy/paste without having to understand or adjust any DNS record elements),
and the potential for conflicting values from combining the records from
multiple Web/CDN providers.

I believe each TargetName still needs to be queried for A/AAAA records,
although the "hints" from the SVCB/HTTPS records are (I believe) intended
to allow the client to at least attempt to avoid the need for that query.

The following would be very different from the existing SVCB/HTTPS proposal:

   - Publish SvcParameters as some sort of RRtype at (or below) each
   corresponding TargetName in the Web/CDN provider's own DNS zone
   - Or, have each Web/CDN provider publish a set of common parameters at
   some namespace within that Web/CDN providers DNS space, and have the
   SvcParams added to the HTTPS (or SVCB) record, by name rather than
   including the values.

Either method (plus optional address hints) could reduce the complexity of
what the domain owner would need to include, simplifying the parsing and
allowing validation of names used (by doing DNS checks in addition to
syntax checks).

If the parameter sets were managed by the Web/CDN provider, and given a
distinct DNS name (and referenced by name rather than value), the
scalability of the bindings would likely improve, e.g. reference via CNAMEs
(with the CNAME targets being long-lived and cacheable).
This would also reduce or eliminate errors, by only having the SvcParams
published by the party that is actually authoritative for them (i.e. the
Web/CDN provider).

The DNS latency issue is quite possibly a separate issue, depending on what
the respective RTTs are for these different DNS relationships:

   - Client - Resolver (RTTc)
   - Resolver - Web/CDN DNS auth server (RTTw)
   - Resolver - Domain Owner DNS auth server (RTTd)

I.e. if RTTc is small (local resolver near the client), and the cache is
populated, I think the multiple-lookup thing becomes a non-issue.
And, conversely, if RTTc is large, I think the wrong problem is being
solved via adding SvcParams to the record in the domain owners' zone.
I'm not sure if the latency changes much (or at all) if the resolver is
HTTPS/SVCB-aware...

These are observations and suggestions, hopefully helpful in keeping the
conversation moving in a productive direction.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 May 2021 14:49:16 -0700

On Tue, May 11, 2021 at 2:31 PM Brian Dickson <[email-masked]>
wrote:
...

> provider is (semantically speaking, not DNS-speaking) "authoritative" for

It sounds like one of the deployment arrangements that is anticipated by
the draft.
...

> own DNS zone, including the TargetName and SvcParameters.

No, as you noted, this is definitely a bad idea, and is not required or
recommended in the draft.  Instead, the domain owner should use CNAME and
AliasMode records to alias to an HTTPS ServiceMode record maintained by the
CDN.  See the Examples section (
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html#name-examples
).

...

> (with the CNAME targets being long-lived and cacheable).

Yes, this is the goal of the draft, and the behavior documented by the
draft's CDN examples.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 11 May 2021 15:43:52 -0700

On Tue, May 11, 2021 at 2:49 PM Ben Schwartz <[email-masked]> wrote:

>
>
> On Tue, May 11, 2021 at 2:31 PM Brian Dickson <
> [email-masked]> wrote:
> ...
>

I'm maybe confused here... I thought the AliasMode (or CNAME) would only
work if there is exactly one CDN provider.
What would the domain owner need to do for having two CDN providers, at
different Priority levels (or at the same Priority level)?

Or in that case, would each TargetName itself point to a name with an HTTPS
(or SVCB) record with its own SvcParams?
I.e. something like this:
foo.example.com HTTPS 1 foo.example.com.cdn1.example.org
foo.example.com HTTPS 2 foo.example.com.cdn2.example.net

(and hosted on their respective domains)
foo.example.com.cdn1.example.org HTTPS 1 . alpn=h2,h3
foo.example.com.cdn1.example.org A <A_RDATA>

foo.example.com.cdn2.example.net HTTPS 1 . alpn=h2,h3
foo.example.com.cdn2.example.net A <A_RDATA>
foo.example.com.cdn2.example.net AAAA <AAAA_RDATA>

Is this something that is likely to be common or at least supported?
If so, it might make sense to put that in as an example of where and how
the actual ALPN binding part is done, where it differs from where the
TargetName is used to link domains.

Brian

> Yes, this is the goal of the draft, and the behavior documented by the

Okay, I think the question/clarification above is what was missing.
Also, if the normal usage by CDN clients (versus CDN operators), where
multiple CDNs are used, does not require any SvcParams, that might make the
concern about the "key=value" lists vs "key,value" RRsets less onerous.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 May 2021 16:00:37 -0700

> different Priority levels (or at the same Priority level)?

Multi-CDN support is described here:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html#name-multi-cdn
It works exactly like multi-CDN works today, juggling multiple CNAMEs to
avoid copying CDN IPs into the customer zone.

I think a standardized mechanism to simplify management of this arrangement
might be useful, but it is largely independent of SVCB and can be developed
separately if there is interest.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 11 May 2021 16:13:13 -0700

On Tue, May 11, 2021 at 4:00 PM Ben Schwartz <[email-masked]> wrote:

>
>
> On Tue, May 11, 2021 at 3:44 PM Brian Dickson <
> I think a standardized mechanism to simplify management of this
> arrangement might be useful, but it is largely independent of SVCB and can
> be developed separately if there is interest.
>

Okay, so let me ask a (stupid) question:

What is the difference between

foo.example.com HTTPS 0 foo.example.net

and

foo.example.com HTTPS 1 foo.example.net

(and assume there is an HTTPS record at foo.example.net, which is the same
in both of those example cases.)

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 May 2021 16:16:04 -0700

On Tue, May 11, 2021 at 4:13 PM Brian Dickson <[email-masked]>
wrote:
...

> (and assume there is an HTTPS record at foo.example.net, which is the
> same in both of those example cases.)
>

In the first case (AliasMode), the ServiceMode HTTPS record of
foo.example.net will be used.
In the second case (ServiceMode), the SvcParams are empty, and only the A
and AAAA records of foo.example.net will be used.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 11 May 2021 16:27:59 -0700

On Tue, May 11, 2021 at 4:16 PM Ben Schwartz <[email-masked]> wrote:

>
>
> On Tue, May 11, 2021 at 4:13 PM Brian Dickson <

What if, instead of overloading the Priority 0 to also mean AliasMode, you
had AliasMode be an SvcParams entry (which, if present, would be the only
param allowed)?
That would handle the AliasMode vs ServiceMode thing, and also allow
MultiCDN.
Assuming that if any RRs have AliasMode, they all must, but also allowing
multiple aliases with different priorities...

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 May 2021 16:51:08 -0700

On Tue, May 11, 2021 at 4:28 PM Brian Dickson <[email-masked]>
wrote:
...

> had AliasMode be an SvcParams entry (which, if present, would be the only

There are of course many possible ways to encode this kind of flag.  I
think using SvcPriority is significantly better than using a SvcParam:
- It allows recursive resolvers to implement full SVCB support without ever
parsing the SvcParams, greatly simplifying implementation.
- It's more compact.
- It allows recipients to sort the RRSet by SvcPriority, then inspect the
top-sorted entry to decide how to proceed.

> multiple aliases with different priorities...

Multiple alias records within an RRSet are deliberately disallowed.
Supporting them would substantially complicate client behavior (which would
acquire multiple layers of retry/fallback) and additional section
processing (which could become very slow and intensive for recursive
resolvers), for no clear gain.

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 12 May 2021 09:41:41 +0200

On Tue, 2021-05-11 at 18:26 +0200, libor.peltan wrote:
> 
> May I be wrong, but I think that name, type, class and TTL are not repeated in one RRSet with multiple RData. Not in wire format and not necessarily even in zonefile. (?)

Zone files allow you to leave some of those out on subsequent records. The wire format does not: https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.3
 
Kind regards,

---

From: Eric Orth <[email-masked]>
Date: Wed, 12 May 2021 15:27:13 -0400

I have no strong opinions on any of the discussions regarding escaping in
presentation mode because I don't have much involvement in dealing with
presentation mode of DNS records.  The client I work with parses wire
format directly into its internal structures.

>From my wire-format-only perspective...

I strongly oppose breaking out the key/value pairs of the current proposal
into separate records within an RRSet.  The "independently meaningful"
records argument in favor of per-endpoint records isn't just some small
nice-to-have but is actually rather crucial to avoiding
inconsistent/missing-data issues that could easily become security issues.
Per-key/value records opens things up to too much error-proneness where the
separate records get cached separately (with potentially differing TTLs),
so there's a lot more room for clients to end up receiving/handling only
some parts of endpoint data without a clear indication that other parts are
missing.  Could be much more problematic than just getting a partial view
of the endpoint options.  Easily becomes a security issue, e.g. when a
client gets most of the records for an endpoint but misses the record
containing the ECH config.

I also oppose allowing multiple aliases within an RRSet.  This would allow
aliasing trees, unreasonably exploding the complexity/performance scope of
query followup logic in stubs and recursives.  In practice, I don't think
this would actually make multiple aliases useful because I would then
expect many stub/recursive implementations (including mine) to only make
followup queries down a single branch of the alias tree.

On Wed, May 12, 2021 at 3:42 AM Peter van Dijk <[email-masked]>
wrote:

> Zone files allow you to leave some of those out on subsequent records. The
> wire format does not:
> https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.3
>
> Kind regards,
> --
> Peter van Dijk

---

From: Brian Dickson <[email-masked]>
Date: Wed, 12 May 2021 13:28:15 -0700

> containing the ECH config.

Sincere apologies in advance for any offense you may take from this.

However...

You are completely mistaken in this concern.

The DNS RFCs collectively, and in their entirety, forbid any of the
following:

   - Breaking up RRSETs
   - Having RRSETs with Resource Records that do not have identical TTLs
   - Servers sending anything that does not comply with this
   - Clients accepting responses with any of these problems (clients are
   required to ignore such responses)

In short, none of the things you present as concerns can occur if the
resolvers or authority servers are at all RFC-compliant.
There is no need to design your protocol to defend against these issues, at
all.
(This is documented clearly in RFC2181, and further referenced for clarity
purposes in the DNS Terminology RFC, RFC8499.)

Responses including partial RRsets are as unlikely (and as illegal) as a
response to a query for SVCB being a TXT record saying "I'm a teapot".

Please take it as read that queries for an RRTYPE will always return an
RRSET which is complete and has uniform TTL values.

Concerns over MITM tampering of results can be addressed by use of DNSSEC,
where the RRSIG (signature) is over the complete RRSET and included with
the RRSET itself. It is literally impossible for a MITM to tamper with a
signed response which will pass the validation by the recipient.

A MITM can just as easily modify the singular RR containing all the
key/value pairs together, so the concern is either moot or invariant
regarding single vs multiple records.

IMNSHO, the wire-format discussion should not be excluded as a result of
your concerns, if the RRSET integrity is your only concern.

Sincerely,
Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 12 May 2021 13:44:06 -0700

> followup queries down a single branch of the alias tree.

The current version of the document only addresses DNS issues which result
from actual attacks. There do not appear to be any logic branches on
timeouts (or other similar failures) other than to abandon the SVCB
handling.

Having multiple AliasMode records within an RRset (with either the same or
different Priority) would provide an avenue for dealing with resolution
failure - which is one of the main reasons for any CDN customer to use
multiple CDNs, i.e. to avoid single points of failure (which includes the
DNS component of the CDN).

I think it would be reasonable to restrict the handling of SVCB processing
to allow multiple AliasMode records in a single RRset in the resolution of
SVCB, i.e. once a branch has been reached, follow the preferred branch
using the existing logic, and either abandon the other branch after the
first successful step in the resolution of the preferred branch, or
alternatively holding the entry point to the second branch (as a backup)
until the first branch's resolution has succeeded to the point of returning
ServiceMode records (and if resolution failure occurs before that point,
switching to the next branch).
This would be the equivalent to keeping a simple list, rather than needed
to handle full recursion tree-walking logic.

This is a suggestion only, but I think it has merit.
The current examples of "juggling CNAMEs" isn't really practical,
especially given TTLs on CNAMEs.
Having multiple RRs in an RRSET with various Priority values achieves the
equivalent function without requiring the domain owner to engage in active
management of DNS records. The latter approach is at best naive, at worst
harmful to deployment and use of SVCB in the real world.

I am a big fan of SVCB, and want it to succeed, so my comments should be
viewed in that light, please. This is about improving the proposal only.

Brian

---

From: Eric Orth <[email-masked]>
Date: Wed, 12 May 2021 17:03:36 -0400

On Wed, May 12, 2021 at 4:28 PM Brian Dickson <[email-masked]>
wrote:

>> I strongly oppose breaking out the key/value pairs of the current
>> proposal into separate records within an RRSet.  The "independently
>> meaningful" records argument in favor of per-endpoint records isn't just
>> some small nice-to-have but is actually rather crucial to avoiding
> response to a query for SVCB being a TXT record saying "I'm a teapot".

Agreed that there is no such issue with either wire format if all parties
in the ecosystem are bug-free and RFC-compliant.  But with all the many
layers and implementations caching DNS, I have a low level of trust that
everyone has read and understood all applicable RFCs and is capable of
applying it all correctly in an implementation.  Thus I still stand by my
point that one wire format here is much more susceptible to potential
caching bugs than the other, and that such issues, while arguably just as
"illegal", are way more likely than receiving a spurious teapot record
(that would be a very impressive bug).

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 May 2021 17:15:33 -0400

On 12 May 2021, at 17:03, Eric Orth <ericorth=[email-masked]> wrote:

> On Wed, May 12, 2021 at 4:28 PM Brian Dickson <[email-masked]> wrote:
> 
>> Responses including partial RRsets are as unlikely (and as illegal) as a response to a query for SVCB being a TXT record saying "I'm a teapot".
> 
> Agreed that there is no such issue with either wire format if all parties in the ecosystem are bug-free and RFC-compliant.

Do you know of an example of a DNS authoritative or recursive server that does return truncated RRSets in the ANSWER section?

I appreciate the value of scepticism when it comes to these kinds of things, but I have never seen any data to suggest that this happens. So much of the DNS depends on correct behaviour here that I'm dubious that this is a real concern. If it's not a real concern, using it as justification for a particular design decision seems worth questioning.

Joe

---

From: Eric Orth <[email-masked]>
Date: Wed, 12 May 2021 17:30:44 -0400

On Wed, May 12, 2021 at 4:44 PM Brian Dickson <[email-masked]>
wrote:

>> I also oppose allowing multiple aliases within an RRSet.  This would
>> allow aliasing trees, unreasonably exploding the complexity/performance
>> scope of query followup logic in stubs and recursives.  In practice, I
>> don't think this would actually make multiple aliases useful because I
>> would then expect many stub/recursive implementations (including mine) to
>> only make followup queries down a single branch of the alias tree.
>>
>

Is the primary concern here resolution failures or connection failures? I
suppose this could help recover from resolution failures, but I would be
surprised if that is the concern in mind when people are configuring
multiple redundant CDNs.

For connection failures, such decisions can only be made on the client
making the connection attempts, so it's not clear to me what behavior we
should suggest for recursives.  I'm already concerned enough with
persuading recursives to do the support here that we want, so unless a
recursive operator/implementor speaks up here to explain why it wouldn't be
an issue, I'm guessing we wouldn't see a lot of full support if we say they
must/should fully follow all branches.

A client could use RFC 8305 (or similar logic) to attempt connections via
one alias branch and move to others (separately queried) only on connection
failures.  But my client doesn't currently support RFC 8305, so we're
unable to reasonably and performantly use separate branches conditionally
on connection failures.  Assuming many other clients would be in a similar
position, I worry that even if we make multiple aliases possible, this
would create a defacto standard that only a single alias is allowed if you
want your domain to be compatible with all the clients.

---

From: "John Levine" <[email-masked]>
Date: 12 May 2021 17:39:03 -0400

>Do you know of an example of a DNS authoritative or recursive server that does return truncated RRSets in the ANSWER section?

A lot return truncated glue in the ADDITIONAL section.  Are we sure that wouldn't be an issue with SVCB?
I honestly don't know.

djbdns would return random subsets of A records if you had a lot of them, as a kind of poor man's load
balancing, but I don't know of anyone who still uses it.

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 May 2021 17:46:26 -0400

> A lot return truncated glue in the ADDITIONAL section.  Are we sure that wouldn't be an issue with SVCB?

I agree that truncation in the ADDITIONAL section is expected. Since the SVCB is expected to be used in RRSets with more than one member RR (different SVCB RRs with the same owner name and class are explicitly contemplated by the draft) it already has to accommodate that (which I think is probably a noop, since it doesn't seem to me that SVCB has different requirements in that regard to any other RRType).

I think Brian's point was that you can rely upon RRSets being intact in the ANSWER section.

Joe

---

From: Eric Orth <[email-masked]>
Date: Wed, 12 May 2021 18:24:51 -0400

On Wed, May 12, 2021 at 6:21 PM John Levine <[email-masked]> wrote:

> >> Agreed that there is no such issue with either wire format if all
> parties in the ecosystem are bug-free and RFC-compliant.
> >
> >Do you know of an example of a DNS authoritative or recursive server that
> does return truncated RRSets in the ANSWER section?
>

Honestly, those aren't the caches I'm worried about.  What worries me the
most is the caching layers between the recursive and the client (e.g.
forwarders and various libraries on the enduser machine, including caching
in various clients themselves).  While I don't have any examples in mind
specifically of these layers messing up RRSet cohesion, there are many
examples of various bugs in these layers (e.g. see all the recent
"name:wreck" fun), and there are a million implementations (hyperbolic) to
worry about.

And given that these layers are typically past the last DNSSEC validation,
there is not a lot here to historically depend on fully correct behavior.
Who would have noticed if some bug in a client means that every once in a
while it's only attempting connections on 4 out of the 5 addresses it's
supposed to have received?

My overall point is that I'm strongly in favor of the wire format with less
potential points of failure in correctly transmitting and stitching
together the individual components of endpoint information that really need
to stay cohesive.

> wouldn't be an issue with SVCB?

Current draft encourages recursives to put followup query results in
Additional.  So maybe truncated glue isn't precisely an issue, but it's
certainly an issue if similar logic leads to incomplete Additional RRSets
reaching the client.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 May 2021 11:15:58 +1000

> On 13 May 2021, at 07:46, Joe Abley <[email-masked]> wrote:
> 

If TC=0, RRsets should always be complete even in the Additional section.
If TC=1, then you may see incomplete RRsets and only in the last section
with records excluding the presence any OPT/SIG/TSIG in the additional
section.

If you see a implementation doing differently then it is broken.

Note IXFR and AXFR may spread a RRset over multiple DNS messages.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 12 May 2021 19:13:48 -0700

On Wed, May 12, 2021 at 3:32 PM Eric Orth <ericorth=
[email-masked]> wrote:

>> >Do you know of an example of a DNS authoritative or recursive server
>> that does return truncated RRSets in the ANSWER section?
>>
>
> My overall point is that I'm strongly in favor of the wire format with
> less potential points of failure in correctly transmitting and stitching

 Unless you have a guarantee that the client can always obtain the full and
complete RRset from the resolver in non-attack situations, you already have
a major problem (i.e. even assuming each SVCB plus SvcParameters is a
single RR, but where more than one SVCB are published in an RRset).

There are multiple problems, if you cannot guarantee the RRset being
delivered to the client:

   1. If an RRset contains both an AliasMode and a ServiceMode record, the
   client MUST ignore all ServiceMode records (per 2.4.1 of the draft). If the
   complete RRset is not returned, the client cannot be guaranteed to pick the
   right record.
   2. If an RRset contains multiple ServiceMode records, the client SHOULD
   start making connection attempts with the highest priority record. If the
   complete RRset is not returned, the client cannot be guaranteed to pick the
   right record(s) in the right order. Note that if the client API to DNS only
   returns a single RR from an RRset, this will not in any way depend on the
   SvcPriority value, as that is an opaque value within the randomly-ordered
   RRset.

So, either the client is guaranteed to get all the RRset members (and the
draft is a viable approach to the intended goal), or it isn't (and it
isn't).
If the guarantee is present and applicable to the existing parts of the
draft, it also absolutely guarantees the necessary preconditions for
combining the key/value elements if they are split into different RRs in
the RRset (rather than one combined entity).

The entire path from resolver to client has to work for the existing draft
to function as intended.
And if it does, it is mathematically impossible for the split key/value
mechanism to not also work.

It is demonstrably more likely that a complex parser will have problems,
than something that combines data from simple RRs in simple RRsets will
have problems.
(The history of SMTP is, I think, a good poster child for this, with MX, A,
AAAA, plus DNSSEC and TLSA support in the clients, which are email
transport things, not merely DNS things.)

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 12 May 2021 21:33:04 -0700

On Wed, May 12, 2021 at 7:14 PM Brian Dickson <[email-masked]>
wrote:

> (The history of SMTP is, I think, a good poster child for this, with MX,
> A, AAAA, plus DNSSEC and TLSA support in the clients, which are email

The SVCB parameters' wire format is an extremely simple TLV arrangement; I
don't think "a complex parser" is required.  It's also far from a novel
design for DNS; in fact, it's identical to the widely implemented OPT RR
RDATA format from 1999 [1][2].

What you're describing here, an arrangement in which clients partition
RRSets into subsets and then reassemble bindings from those subsets,
strikes me as highly novel, in contrast, and somewhat more complex.

Perhaps complexity is subjective.  The important thing is that the standard
be reasonably implementable.  I hope that the list of published
implementations [3] will serve as convincing evidence that the current
draft is sufficient in that regard.

--Ben

[1] https://datatracker.ietf.org/doc/html/rfc2671#section-4.4
[2] https://datatracker.ietf.org/doc/html/rfc6891#section-6.1.2
[3]
https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md

---

From: "John R Levine" <[email-masked]>
Date: 13 May 2021 00:43:36 -0400

>> transport things, not merely DNS things.)

Not really.  MX and A mean different things, and it is useful and common 
for an SMTP server to be pointed to via MX and A with different names.

> RDATA format from 1999 [1][2].

Having written some DNS parsers, I agree.  Parsing the fields out of the 
wire format is easy.  I have reservations about SVCB but the encoding 
is not one of them.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 May 2021 00:50:57 -0700

On Wed, May 12, 2021 at 9:33 PM Ben Schwartz <[email-masked]> wrote:

> On Wed, May 12, 2021 at 7:14 PM Brian Dickson <
> don't think "a complex parser" is required.
>

This is an apples/oranges argument, the parsing complexity I'm referring to
(I thought explicitly, but I guess that is too far up-thread) is the
presentation (aka zone file) format.
The initial opinions (not just mine) were that the format, while maybe
familiar to HTTP implementers, is very un-DNS-like, and the proposition was
that the complexity was not strictly necessary.

While combining multiple simple records into a complex record, in wire
format, would not be difficult, it is not what DNS authority servers do,
and is not what resolvers do.

But, the _wire format_ of the original proposed record is not at issue, and
never has been, so I don't understand why you bring that up.

> It's also far from a novel design for DNS; in fact, it's identical to the
> widely implemented OPT RR RDATA format from 1999 [1][2].
>

That is actually an interesting point, for one very important reason: NONE
of the OPT RR elements are zone file constructs. They are all metadata,
typically established by the configurations of various implementations of
DNS clients and servers (including authority servers and resolvers).

So, you are actually making the point for me, that the wire format of
something that isn't a zone file component, can be complex and trivial to
parse. We agree on this completely. The TLV aspect is well understood, and
a component of many protocols (e.g. BGP, another protocol I'm actively
involved in via the IDR WG).

Having complex records in zone files is unwise, if it is not strictly
required.

The question was raised, as to whether that format is strictly required,
and I think the consensus is that it is not.

> strikes me as highly novel, in contrast, and somewhat more complex.

It is a simple table join using a single key. It was unabashedly ripped off
from the RDBMS field of programming. Or actually COBOL, from the early
1980's. It's a hack, slightly clever maybe, but extremely simple and
reliable.
The requirement that each SvcParameter occur only once, is actually
enforced directly via the 4-tuple uniquess criteria for DNS: owner, class,
type, RDATA. If the RDATA consists of priority, enum, key, value pair, DNS
enforces the uniqueness automatically.
(This technically makes the semantic component of what would otherwise be a
complex parser moot, and the syntactic part, the easy part, is all that
needs to be implemented.)
This also vastly simplifies the encoding/decoding of unknown RDATA, since
the priority, enum, and key are numeric values of fixed size, leaving a
single "value" component.

The enumerator is the key (for the table join). The client does not need to
check parameter uniqueness. It only needs to match up the enums to recreate
the JSON of the objects in the array of structures (or regroup them into
the OPT RR wire format if you prefer).
This is the absolute simplest thing to code, and the absolute furthest
thing from "novel". Its use as an encoding in DNS might be new, but it is
the kind of thing that unit tests can handle trivially.

So, to be clear, I'm only explaining the what and how, and maybe some parts
of the why. I'm not in particular advocating strongly for using it, only
presenting it as a viable option, for other folks to discuss the merits of.

>
> Perhaps complexity is subjective.  The important thing is that the
> standard be reasonably implementable.  I hope that the list of published

Implementable isn't the same as maintainable or simple to debug, or to
confirm interoperability. This is particularly a concern across situations
of zone file export, copy, and subsequent import on all of the other
implementations. You may be underestimating the number of implementations.
Switching to a zone file format that is simpler to parse would go a long
way to improving those.

Brian

---

From: "libor.peltan" <[email-masked]>
Date: Thu, 13 May 2021 12:55:58 +0200

Hi all,

just my comment:

> standard be reasonably implementable.  I hope that the list of 
> published implementations [3] will serve as convincing evidence that 
> the current draft is sufficient in that regard.
>
> --Ben
>
I agree that complexity is subjective. I have no problem implementing 
complex procedures. But more complexity means more probability for bugs 
(and even security issues).

Currently, the authoritative server (while transforming presentation to 
wire format), MUST:

  - sort the SvcParams by key
  - verify their uniqueness
  - deal with list of fields nested in other fields (this includes the 
discussed comma escaping)

and the client MUST:

  - verify that SvcParams are sorted and unique
  - deal with list of fields nested in other fields (at least that 
various "lengths" match)

In the concurrent proposal, the sorting and deduplication will be "for 
free", because DNS ensures this, and each RData would consist on just 
one list of values, much easier to handle.

On the other hand, the client would have to group several RData (already 
sorted) to get all info, and believe they're all there (as Brian pointed 
out, it has to anyway). And it would cost more bandwith due to DNS 
overhead -- repeated TTLs etc (thanks Ben and Vladimir for the lesson).

Have I summarized the pros/cons of both approaches well enough?

Libor

---

From: Eric Orth <[email-masked]>
Date: Thu, 13 May 2021 11:29:07 -0400

On Thu, May 13, 2021 at 3:51 AM Brian Dickson <[email-masked]>
wrote:

>> The SVCB parameters' wire format is an extremely simple TLV arrangement;
>> I don't think "a complex parser" is required.
>>
>
> This is an apples/oranges argument, the parsing complexity I'm referring
> to (I thought explicitly, but I guess that is too far up-thread) is the
> But, the _wire format_ of the original proposed record is not at issue,
> and never has been, so I don't understand why you bring that up.
>

A lot of the recent debate here has delved into the fundamental structuring
of how SVCB info is divided into records.  That very much affects both
presentation and wire format.

I really prefer the current wire format over most of the suggestions in
this thread, but I don't really have any strong opinions regarding
presentation format.  Making presentation format split things into multiple
"records" but stitching it up into a single wire record isn't a reasonable
option, right?

> It is a simple table join using a single key. It was unabashedly ripped
> off from the RDBMS field of programming. Or actually COBOL, from the early
> (This technically makes the semantic component of what would otherwise be
> a complex parser moot, and the syntactic part, the easy part, is all that
> The enumerator is the key (for the table join). The client does not need
> to check parameter uniqueness. It only needs to match up the enums to
> recreate the JSON of the objects in the array of structures (or regroup
> them into the OPT RR wire format if you prefer).
> So, to be clear, I'm only explaining the what and how, and maybe some
> parts of the why. I'm not in particular advocating strongly for using it,
> only presenting it as a viable option, for other folks to discuss the
> merits of.
>
>
>>

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 13 May 2021 10:25:11 -0700

> presentation (aka zone file) format.

Ah, so you were comparing the difficulty of a complex parser (at the
authority) to combining data from RRs (on the client).

> that the complexity was not strictly necessary.

SVCB's key=value zone-file format is borrowed straight from DNS-SD (RFC
6763); it is not new to DNS users.

> and is not what resolvers do.

It is not, at present, what any components do, and the current draft is
designed to keep it that way.

> The requirement that each SvcParameter occur only once,
>

This is not the current draft's requirement.  The requirement is that each
key appear only once, to avoid conflicting values.

> single "value" component.

I don't see any simplification.  The length of each value is explicit in
the TLV, so unknown keys are equally straightforward to handle.

> them into the OPT RR wire format if you prefer).

The SVCB draft makes no mention of JSON, but I presume you mean any
application-specific representation of the service binding.  I understand
that it would be possible to reconstruct bindings from labeled records
spread across the RRSet in the way you're describing, but simply encoding
each binding into a record seems much more straightforward.

> This is the absolute simplest thing to code
>

Breaking the binding into pieces creates many new opportunities for error,
such as having multiple TargetNames in a single binding.  It corresponds to
a multimap datastructure instead of a standard map.  Every attribute of
each binding would naturally be an unordered collection, which is a bad fit
for attributes that are required to be singular, or an ordered list, or
anything other than a set.

> way to improving those.

Separating the binding into separate records transfers complexity from zone
file implementors to zone file authors, who must express a simple key=value
map by writing multiple records using explicit binding indexes.  For a
human reading a zone file, it is particularly difficult: a single binding
could be broken up into records separated across the zone file, with
surprising consequences if you forget to clean one up, typo a binding
index, or accidentally create an index collision between two bindings.

I continue to prefer the draft's current format.  It hews closer to DNS
tradition (wire format from OPT, zone file format from DNS-SD).  It avoids
the novel paradigm of cross-RR reconstruction.  It is not speculative,
having now been validated by at least a dozen full-production
implementations.  It is more efficient on the wire.

Considering alternative formats is an intriguing exercise, but I do not
think it is likely to result in improvements to SVCB.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 13 May 2021 10:50:04 -0700

On Thu, May 13, 2021 at 3:56 AM libor.peltan <[email-masked]> wrote:

>  - deal with list of fields nested in other fields (at least that various
> "lengths" match)
>
> free", because DNS ensures this,
>
DNS only ensures that each entire record appears only once, which is
different from the current draft's requirement that each key appear only
once (to form a map).

> and each RData would consist on just one list of values, much easier to
> handle.
>
I'm not sure I understand.  Are you proposing that each record contains a
single value, or each record contains multiple values?  If the former, note
that you have a "set" of values, not a "list"; order is not preserved.  Any
value type that is actually an ordered list will have to complicate its
value format in order to express the ordering.  If you mean for each record
to contain multiple values, then you either have multiple layers of
redundant multiplicity (sets of lists), or you require that clients
validate the RRSet to ensure there are no duplicate keys.  Either way, you
have to consider who is responsible for preventing multiple values for
single-valued parameters, whereas in the current draft, this is essentially
inexpressible.

> out, it has to anyway). And it would cost more bandwith due to DNS overhead
> -- repeated TTLs etc (thanks Ben and Vladimir for the lesson).
>
I would also add the considerations for humans who are reading or writing
zone files.  Can they see bindings as a unit, with confidence?  Is the
syntax familiar and self-explanatory?  Is it excessively verbose?  Are
typos likely to be caught early, with helpful error messages?

---

From: "John R Levine" <[email-masked]>
Date: 13 May 2021 13:59:47 -0400

> 6763); it is not new to DNS users.

Hey, wait a minute.  DNS-SD just sticks the "key=value" strings as-is into 
text fields.  Now that I look closer, I see what Brian's objection is and 
I have a lot more sympathy for it.

No other RRTYPE has master file processing anywhere near as complicated as 
this:

~>  - sort the SvcParams by key
> discussed comma escaping)~

If you put the SvcParams into text strings and let the client sort it out, 
I think the objections would go away.  This would mean that there could be 
zone files with semantically invalid SVCB records, yes, but that's nothing 
new, and the client has to check for that anyway.

Look at NAPTR.  It has a reputation for being very complicated but the DNS 
part is trivial, just a few numbers and strings.  The heavy lifting of 
regular expression matching all happens in the client.  If someone 
publishes a NAPTR with an invalid regexp, that's not the master file or 
server's problem.  It's something to catch at a higher level.

Regards,

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 13 May 2021 11:22:47 -0700

On Thu, May 13, 2021 at 10:59 AM John R Levine <[email-masked]> wrote:

> I think the objections would go away.

That's possible, of course, but it would be much less efficient.  HTTPS
records are intended for use at the start of every HTTP connection;
eventually they could be almost as frequent as AAAA.  They can also contain
relatively large binary objects (e.g. public keys for Encrypted Client
Hello).  A text-based format was deemed insufficiently compact for this use
case.

Pushing text processing onto the client does not reduce the complexity; it
just moves it to people who are less likely to be reading DNSOP.  Notably,
it moves that responsibility to a place where typical text processing
errors are far more dangerous, and malicious inputs are far more likely.

In addition to being safer, performing parsing at the authority also
improves early detection of typos and syntax errors.  In a textual format,
errors would be much more likely to be detected only after they cause an
incident, or to be overlooked entirely if the failure is silent.

The complexity of the zone file format is significant, but the existence of
multiple production implementations suggests that it is not unmanageable.

---

From: "John R Levine" <[email-masked]>
Date: 13 May 2021 15:23:56 -0400

> errors are far more dangerous, and malicious inputs are far more likely.

I suppose, but it also moves it to people who are more likely to care.

I don't know if you've looked at the state of DNS provisioning software, 
but it is pretty bad.  While I'm sure that bind and nsd and powerdns can 
handle anything, I', also sure that approximately nobody outside of a few 
large sophisticated sites will use SVCB because their local DNS 
provisioning crudware doesn't support it.  If you can say it's easy, it's 
a couple of numbers and strings, they might.  If they have to parse and 
sort and dedup and look up code numbers, uh, sure, maybe later.  Much, 
much, later.

Regards,

---

From: Brian Dickson <[email-masked]>
Date: Fri, 14 May 2021 15:53:58 -0700

On Thu, May 13, 2021 at 10:50 AM Ben Schwartz <[email-masked]> wrote:

>> So, I gave some thought to the problem space, and went back and looked at
a bunch of RFCs regarding new RRTYPEs, handling unknown RRTYPEs, etc., as
well as giving thought to the basic goals for which SVCB/HTTPS is a
proposed solution.

It's not a great situation.
(Feel free to skip ahead, this is way too long and possibly both moot and
ridiculous.)
Here's what I've found out (or refreshed my memory on) which impacts the
design decisions and possible alternatives (with some caveats and
pros/cons):

   - RFC5507 recommends against anything new using subtypes (particularly
   as selectors). That is an informational RFC, but authored by the IAB.
   - RFC6950 expands on RFC5507, but doesn't have much relevant guidance
   beyond what RFC5507 says i that regard.
   - RFC3597 governs handling unknown RRTYPEs. Basically it allows for them
   to be handled (thus making new RRTYPEs deployable generally), but has a
   side-effect of "no special handling" (additional processing).
   - RFC2181 details/updates how TC=1 should be set, and how clients should
   handle TC=1 responses.
   - RFC403[345] and RFC5155 (and any updates) have guidance for any
   section other than the Answer section, versus regular RRSETs and their
   RRSIGs.

The 5507 guidance suggests using either distinct RRTYPEs, or underscore
selectors, or both, rather than subtypes. However, either of those would
require multiple queries to obtain records, so there would be a performance
impact for doing that.
The 2181 rules basically mean putting anything additional in the Additional
section, isn't guaranteed to fit, and won't trigger TC=1 if it doesn't.
The 4035 rules require additional sections to include RRSIGs along with
RRSETs, but only if they all fit. It allows responses to exclude RRSIGs
even while still including signed RRSETs in the Additional section.
The original RFC1035 specifies CNAME format and handling, and this is
confirmed by 2181: it is a singleton (both RRTYPE and number of them
permitted). (See below for why that is important). Other than SOA, there do
not appear to be any other "singleton" RRTYPEs enforced by authority
servers or resolvers.

For some new RRTYPE to be deployable, it would need to be able to be
handled via RFC3597 rules. That precludes any new RRTYPE that has
Additional processing (before full deployment across the ecosystem), or
requirements to be a singleton RRTYPE (only one tuple permitted of that
type).
Even after full wide scale deployment, it would be difficult (if not
impossible) to ensure the singleton key rule on a subtyped RRTYPE. (That's
one of the complexity issues).
It would be much more feasible to enforce rules for singleton tuples if the
"key" were actually the RRTYPE, and that would imply needing several. RFC
5507 definitely supports this methodology, and the RRTYPE space (16 bits)
is large enough for that to be very reasonable.
However, obviously, the need for multiple queries is in conflict with the
goal of low latency, with the goal being getting all the records with a
single query (QTYPE).
It might be possible to request a new meta-type, similar to the behavior of
the deprecated QTYPE of MR (which returns any of 3 RRTYPEs).
Or, it might be possible to replicate the EDNS flag behavior of DO, to ask
for related record types to be included in the Answer section (instead of
the Additional section).
Both of those are not really feasible to expect deployment in the short
term.

Before reading further, please be warned. To quote Douglas Adams' Deep
Thought, "You're really not going to like it."
You've been warned...

In order to have a solution that is deployable now, and can guarantee the
uniqueness at a key level (enforced by existing DNS rules), it is necessary
to use CNAME chains, and encoding of keys and values as domain names.
(Note that I'm not actually suggesting this seriously; I'm presenting it as
a reason to not expect the DNS as currently deployed to handle the
uniqueness problem.)

I said you weren't going to like it.

Here's why that would work, and how it would work, if someone wanted to
implement things this way:

   - Assume the CNAME chain goes from a representation of "key" to a
   representation of "value"
      - There can only be one CNAME record at that "key", so both the "key"
      and "value" are singletons
   - The CNAME chain is a well-ordered sequence.
      - Thus, if the UI managing this knew about the numeric values for the
      keys, it could keep them in sorted order (numerically).
   - If the entire set were in the same zone, the entire chain would
   generally be served in a single response (if it could fit in the Answer
   section without triggering TC=1). A single query would return the whole
   encoded chain.
   - A resolver would cache the whole chain, even if it did not know about
   the final RRTYPE at the end of the chain.
   - A client making a query would receive the whole chain from a resolver.
   - The presence of multiple matching records would require a combined
   (double-length) chain.
      - (Trying to encode two single-chain things at the same owner name is
      not allowed per CNAME rules.)
   - The last name in the CNAME chain would probably need to own some new
   RRTYPE (exclusively).
      - This would ensure there is no conflict resulting from using any
      existing QTYPE.
   - The names used for encoding would probably need to be
   underscore-prefixed, or at least children of an underscore-prefixed name.

I could give an example of this encoding, but I think this is already long
enough and silly enough. Unless anyone wishes to take this further.

> typos likely to be caught early, with helpful error messages?

I think it should be taken as a safe assumption, that for the vast majority
of end users, they will either be using some kind of UI (good, bad, or
ugly) that is (eventually) aware of the relevant RRTYPE(s), or using one or
more tools that do validation of the zone file (as part of the process of
adding new records), or using software for serving the zone(s) which does
the necessary checks as part of the start-up or zone-loading process (and
prevents illegal stuff, including things like "CNAME and other RRTYPE at
same owner name", or "Multiple CNAMEs at same owner name".
Obviously using encoding via RFC3597 would not have any special checks, so
very early adopters would need to be aware of the issues. I don't think
that's the issue here, though.

Humans can edit zone files and make errors, but generally, if an RRTYPE is
known, there will be a bunch of checks to make sure the zone file conforms
to all the specified requirements.

Of course, the simpler the RRTYPE is to parse, the more reliable that
process will be (particularly for new RRTYPEs, for which the parsing and
validation is new).

Brian

---

From: "John Levine" <[email-masked]>
Date: 14 May 2021 20:47:15 -0400

>I said you weren't going to like it.

No disagreement there.

>same owner name", or "Multiple CNAMEs at same owner name".

Perhaps, or in a lot of cases, the web hosting provider gives the customer the
DNS records to copy and paste into their DNS provider's console.

This tells us that in practice, any sort of complex master file format is
a waste of effort.  If the users are going to copy and paste, they might
as well copy a base64 blob and not worry about making it easy to read.

The wire format can be the same as what it is now.

R's,
John

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 14 May 2021 18:10:16 -0700

On Fri, May 14, 2021 at 5:48 PM John Levine <[email-masked]> wrote:
...

> If the users are going to copy and paste, they might

Thanks to RFC 3597, there's no need to define opaque zone file formats for
new records.  Opaque input (in hex) is always an option, so the
type-specific zone file format can be something more legible, and RFC 3597
format is always available as a fallback if the type-specialized format
isn't implemented in some system.

BTW, SVCB does define a way to represent parameters in wire format verbatim
(e.g. key4=\192\000\002\001), in case a new SvcParamKey is not supported by
a particular implementation.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 14 May 2021 18:11:35 -0700

> DNS records to copy and paste into their DNS provider's console.

While it may not have yet achieved ubiquitous use in the web hosting space,
DomainConnect is a method used by quite a few providers, and supported by a
number of DNS providers.

DomainConnect uses a template mechanism, where the service provider (in
this case, web hosting provider) supplies values that correspond to
variable in the template.

In that particular use case, having a template that has simple encoding
makes the interoperability much more reliable.

The biggest benefit of using a scheme with one key/value pair per line, is
the substitution is dead easy. No escaping or quoting problems.

It isn't necessarily meant to be read by the user, but if they choose, it
is visible.

(The particulars of DomainConnect are basically, the service provider has a
UI thing that takes the user to an auth page for the DNS provider, and
after authenticating, magic happens.)

Brian

---

From: Erik Nygren <[email-masked]>
Date: Sat, 15 May 2021 11:00:38 -0400

> harmful to deployment and use of SVCB in the real world.

A question would be whether this adds more to client complexity than even
advanced clients would
be willing to implement.  Multiple Alias records pointing to independent
CDNs is only useful if clients
pop all the way back to that point to try another tree in the case where
connecting to the services
at the end of the first Alias record path fails.

This also only covers a small number of the "juggling CNAMEs" multi-CDN
setups today.
Many/most seem to take factors of cost, geographic location, and
performance into account,
so multiple Alias records wouldn't solve this but would just add another
place for more complexity.

     Erik

---

From: Brian Dickson <[email-masked]>
Date: Sat, 15 May 2021 12:48:14 -0700

> think it is likely to result in improvements to SVCB.

So, my first alternative format (for splitting out key/value pairs)
involved adding another component to the record format, which (as you
noted) allowed for multiple instances of TargetName.
Here it is again for reference:

> For the AliasForm, both the Priority and Enumeration would be 0, and only
> a single Target,Value pair are permitted.

2 2 ech "abc..."

So, taking your observations about TargetName into account, and borrowing
from the overloading of Priority to signal AliasMode, here's an alternative
that I think addresses most of the concerns.
Priority {AliasTarget | ServiceTarget | KeyName}
{ServiceBindingPriorityValue | Value}
where
Priority == 0 => AliasMode
Priority >0, <128 => ServiceMode
Priority > 128 => ServiceBinding key-value record

The same example would be encoded (again with only RDATA values):

> 1 target "h3pool" 128

> 128 alpn "h2,h3"

> 128 ech "123..."

> 2 target "." 129
129 alpn "h2"
129 ech "abc..."

The Priority values are sortable (as required), and sorting all the records
has the side-effect of grouping the key/value pairs.
If desired, the key/value pairs can be sorted by the first two fields
(priority and key) to check for uniqueness before use.
The look-up of keys and values, or the recombining into some arbitrary
structure (whatever the output of parsing the wire format from the current
proposal is), seems straightforward.
The parsing of each record's presentation (zone) format is as simple as
whatever each individual parameter's format requires/allows.

And, there is no longer any ability to introduce duplicate target names in
a single record reconstruction, as the ServiceMode record is distinct from
the key/value set.

If necessary, the presentation and wire formats for key/value records could
add an extra "." to avoid burning the Code Point already allocated. That
"." would simply be ignored, and add one byte (I think) to the wire format,
plus the other relative inefficiencies already noted.

I think this is sufficiently different from the earlier encoding, to be
worth consideration.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Sat, 15 May 2021 13:05:18 -0700

On Sat, May 15, 2021 at 8:00 AM Erik Nygren <[email-masked]> wrote:

> On Wed, May 12, 2021 at 4:44 PM Brian Dickson <
>> Having multiple AliasMode records within an RRset (with either the same
>> or different Priority) would provide an avenue for dealing with resolution
>> I think it would be reasonable to restrict the handling of SVCB
>> processing to allow multiple AliasMode records in a single RRset in the
>> resolution of SVCB, i.e. once a branch has been reached, follow the
>> preferred branch using the existing logic, and either abandon the other
>> branch after the first successful step in the resolution of the preferred
>> branch, or alternatively holding the entry point to the second branch (as a
>> backup) until the first branch's resolution has succeeded to the point of
>> returning ServiceMode records (and if resolution failure occurs before that
>> point, switching to the next branch).

Currently, the singular AliasMode (chain, but non-forking chain) still
requires potentially multiple ServiceMode records to be handled, including
queries for A and AAAA records for the TargetNames (or inclusion of those
by the Authority server etc.)
Resolving each AliasMode chain (if a single single sit "fork" occurs) to
the ServiceMode records of all the forks, would result in a set of
ServiceMode records. All of the handling of ServiceMode records from each
of the forks could be done effectively the way they are today, with the
results of each ServiceMode's evaluation being kept in the sorted order (as
is already the case).

It goes from the current method of:
AliasMode -> .... -> sorted list of ServiceMode records (possibly sorted in
random order if two or more of the same SvcPriority exist)
to:
Priority-sorted AliasMode set -> ... multiple sets of ServiceMode records
[each set corresponding to the AliasMode], respectively sorted within those
groupings according to the SvcPriority of the ServiceMode records within
each set.

The words are more complex than the implementation; the end result can be
treated as a single sorted list (and handled by whatever existing code for
handling connections and failures from the singular AliasMode case).

> place for more complexity.

There are almost no multi-CDN setups today, BECAUSE of the lack of
SVCB/HTTPS records.
If a CDN customer is making use of any sort of non-standard apex "cname",
they CANNOT use multiple CDNs.

Reading more into the "why" of almost no multiple-CDN setups than that, is
{insert appropriate logical fallacy name here}.

There are additional reasons for needing multiple CDNs, on at least a
temporary basis, such as migrating between CDN providers.

And finally, the use of same-priority multiple CDNs allows the client to
pick the best choice of destination based on local network effects
(latency, loss). This may not be the case at initial connection time, but
might be relevant over the longer term.
What is optimal for behavior on a cold cache, may not continue to be
optimal on a warm cache, or during global or local network issues.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 17 May 2021 14:35:28 -0700

> The same example would be encoded (again with only RDATA values):

I find this format, with multiple lines and multiple integers per binding,
much more difficult to read or write than the current draft, especially
since the elements of each binding can potentially be spread across a zone
file (perhaps by accident) in arbitrary order.

> has the side-effect of grouping the key/value pairs.

Depending on how you choose your priority pairings, it looks like sorting
can actually mis-group the pairs and target-names.

Perhaps this can be sorted out somehow but I don't think this represents an
improvement over the present draft.

...

> whatever each individual parameter's format requires/allows.

It sounds like you're proposing to use exactly the same type-specific value
parsing as specified in the current draft.  That parsing logic for various
key types represents the majority of the implementation effort.  The only
element this format eliminates is the key=value syntax, which is a small
part of the implementation.

> a single record reconstruction, as the ServiceMode record is distinct from

This is not true.  In this format, two "target" records with different
TargetNames can be written with the same priority, and logic is presumably
needed somewhere to prevent this.

> add an extra "." to avoid burning the Code Point already allocated.
>

The wire format that you've proposed is not meaningfully compatible with
the current SVCB draft, so it would need a separate codepoint regardless.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 17 May 2021 14:46:13 -0700

Here is a slightly deeper dive into this alternative scheme (for zone
file/presentation and wire format), in terms of both the encoding, and the
specification document itself (and as a result, the IANA components).

I re-read (several times) the current -05 version of the draft. I found it
difficult to follow and understand several aspects of the "automatically
mandatory", "mandatory", and mandatory usage in the document, both
syntactically and semantically.
The actual binding specifications also were either incomplete or confusing,
with respect to the mandatory/"mandatory" things.
(Default values for alpn, plus the "alpn" parameter, and "no-default-alpn"
were similarly a bit hard to follow, and/or hard to surmise from only the
binding entry.)
The list of parameters within a binding, versus across bindings, was also
somewhat ambiguous, which for subsequent bindings (e.g. from new RFCs after
this become an RFC) could be confusing or even result in conflicting
bindings.

Here are some specific suggestions, including incorporating the updated
proposed encodings:

   - Use the term MTI (mandatory to implement)
      - MTI parameters would be "alpn", (maybe) "no-default-alpn", and
      (maybe) "port"
      - The IANA table in 14.3.2 really needs an MTI column in addition to
      the other columns
   - For each binding registry, an additional table column specific to that
   registry should be included/added: "non-negotiable", i.e. MTI for this
   binding.
   - Replace the "mandatory" thing, with an "optional" flag to be
   optionally appended to any parameters that are not "non-negotiable".
      - This also removes the need to have a sorted list of mandatory
      attributes
      - Each binding will have a list of non-negotiable attributes, which
      can be used for validating the "optional" flag on both the authority side
      and the client.
      - Any parameter that is not non-negotiable, but does not have the
      optional flag, must be supported by the client for the parent HTTPS/SVCB
      record to be accepted by the client.
   - The binding tables then become lists of parameter sub-types that the
   specific binding uses, marked as optional-allowed or non-negotiable. The
   binding table incorporates all the MTI sub-types as well.
   - The binding tables obviously still need default values (if
   appropriate), e.g. for ALPN.

The HTTPS binding would then consist of:

   - Default ALPN of "http/1.1"
   - MTI of "alpn"
   - NN of "port"
   - NN of "no-default-alpn"
   - Optional of "ecn"
   - Optional of "ip4hint"
   - Optional of "ip6hint"

And an HTTPS referenced record (included by reference from record with
SvcPriority between 1 and 127), would have the following rules:

   - Any "optional" parameter MUST be implemented by the client, UNLESS the
   "optional" flag is present in the HTTPS referenced record
   - This rule applies to "ecn", "ip4hint", and "ip6hint" records (each has
   its own "optional" flag, and that flag is only applicable to the parameter
   associated with the main HTTPS record linking to the parameter).

I'll follow up with examples, that correspond to the examples in the
original document.

Brian

On Sat, May 15, 2021 at 12:48 PM Brian Dickson <
[email-masked]> wrote:

>> Breaking the binding into pieces creates many new opportunities for
>> error, such as having multiple TargetNames in a single binding.  It
>> corresponds to a multimap datastructure instead of a standard map.  Every
>> attribute of each binding would naturally be an unordered collection, which
>> is a bad fit for attributes that are required to be singular, or an ordered
>> list, or anything other than a set.
>>
> The Priority values are sortable (as required), and sorting all the
> records has the side-effect of grouping the key/value pairs.
> If necessary, the presentation and wire formats for key/value records
> could add an extra "." to avoid burning the Code Point already allocated.
> That "." would simply be ignored, and add one byte (I think) to the wire
> format, plus the other relative inefficiencies already noted.
>

---

From: Erik Nygren <[email-masked]>
Date: Mon, 17 May 2021 17:58:09 -0400

> file (perhaps by accident) in arbitrary order.
I concur with Ben here.  Thank you for spelling out and proposing this
alternative, but this seems much less usable
and understandable by a typical user, either for zone publication or for
reading diagnostic output from tools
like "dig" or for talking about in other drafts specifying SVCB.

Side-note: some precursors to SVCB and earlier discussions in the working
group
proposed using a standardized format such as CBOR for encoding the
SvcParams but
that approach was discarded as bringing in a bunch of its own baggage and
being too
different from typical DNS usage.

An approach HTTP took was to define "Structured Field Values for HTTP"
(rfc8941)
which may be more complexity than is needed here, but perhaps there
is a similar approach that could work for SVCB of defining explicit types
for SvcParamValues?

Another approach could be seeing if there was a way to require
everything to use a limited character set and require escaping
for things outside of these constraints.  For example, alpn values
with a limited set of token characters would be allowed as strings,
but anything else would need escaping.  Would require base64 encoding
of SvcParamValues wanting characters outside of "non-special"
be easier to parse, perhaps with a prefix to indicate that a string is
base64 type?
Are there other similar things that would keep the format similar to the
existing
format but reduce the number of parser special-cases needed?

     Erik

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 17 May 2021 15:48:31 -0700

> syntactically and semantically.

I'm sorry this wasn't clear.  The text at the top of Section 7 defines the
terminology

   In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the
   RR will not function correctly for clients that ignore this
   SvcParamKey.  Each SVCB protocol mapping SHOULD specify a set of keys
   that are "automatically mandatory", i.e. mandatory if they are
   present in an RR.

...

>       - The IANA table in 14.3.2 really needs an MTI column in addition
>       to the other columns
>
> In the HTTPS protocol mapping as presently defined, there are no MTI
parameters.  A compliant client implementation might not have any supported
parameters.  We could add a row for this in the table, but its value would
be "none".  (Future mappings may indeed have MTI parameters.)

As the table notes, the "automatically mandatory" parameters are
"no-default-alpn" and "port".  A client that doesn't support any parameters
would ignore any record that contains these parameters.

>
>    - For each binding registry,
>
> Mapping documents are IETF-controlled, not IANA-controlled, so there isn't
a "registry" per se.

an additional table column specific to that registry should be
> included/added: "non-negotiable", i.e. MTI for this binding.

A "service binding" is a single SVCB RR; I presume you mean the "mapping",
a document that defines how to use SVCB in some context.

It sounds like "non-negotiable" is a synonym for "automatically
mandatory".  I'm certainly open to changing the draft's terminology.
"non-negotiable" might be clearer, although I'm not sure what negotiation
it's describing.

> It sounds like this "optional" flag is exactly the inverse of the present
"mandatory" indication.  The present structure was chosen in part to
simplify the zone file and wire formats, by avoiding an additional mark
that must be written or parsed on every SvcParam.  Additionally, for
compatibility, it seems likely that the great majority of parameters will
either be automatically mandatory (as specified in the mapping document) or
optional (especially if they are introduced later), so making parameters
mandatory unless marked otherwise seems like the wrong default.

> I'm not sure what you're describing, but note that new parameters can be
defined over time, and we do not want every new parameter draft to Update
the SVCB RFC.  The proposed parameter registration policy is
first-come-first-served, with the understanding that clients will normally
ignore new parameters that they do not recognize.

> Note that declaring alpn to be "MTI" would have no effect.  As presently
defined for HTTPS, the "alpn" SvcParamKey only adds advertised protocols.
If you prefer to stick to the default protocol (TLS over TCP), you can
"implement" the alpn parameter by ignoring it.

>    - aNN of "port"
>    - Any "optional" parameter MUST be implemented by the client, UNLESS
>    the "optional" flag is present in the HTTPS referenced record
>
> It seems you are drawing distinctions between "mandatory to implement",
"non-negotiable", "optional", and "flagged optional".  I don't believe this
is a simpler formulation than the current draft.  By working through an
alternative formulation, I think you've shown that the complexity is
irreducible.

I continue to prefer the current draft, as it provides the correct behavior
in ordinary cases with simple inputs like

1 . alpn="h2,h3" ech=...

---

From: Brian Dickson <[email-masked]>
Date: Mon, 17 May 2021 23:00:35 -0700

On Mon, May 17, 2021 at 3:48 PM Ben Schwartz <[email-masked]> wrote:

> On Mon, May 17, 2021 at 2:46 PM Brian Dickson <
>> I re-read (several times) the current -05 version of the draft. I found
>> it difficult to follow and understand several aspects of the "automatically

Okay, so if I understand this correctly, a compliant client would NOT need
to understand "alpn" as an SvcParameter for HTTPS?
But it would need to understand the "default" ALPN of "http/1.1"?

That's ... interesting. The terminology and tables should probably try to
make that more obvious.

>> Mapping documents are IETF-controlled, not IANA-controlled, so there
> isn't a "registry" per se.
>

Also kind of interesting. The purpose of IANA is to publish useful
information related to standards, at least that's my take on it.
Those tables ARE THEMSELVES IETF-controlled via whatever rules apply. IANA
does not do anything unilaterally.
(Examples would include things like 'RFC required', or 'Expert review', or
'Standards Action', at least in the DNS tables.)

I don't understand why you are making that distinction? Or why IANA table
updates via new RFCs (without necessarily altering either existing table
entries or prior RFCs) aren't compatible with that intent?

> a document that defines how to use SVCB in some context.

Yes, I meant mapping, as in the protocol definition for an RR type that
implements any SVCB protocol-specific record, including what defaults are,
what SvcParams are in-scope (and possibly newly defined), etc.

>>       - Each binding will have a list of non-negotiable attributes,
>>       which can be used for validating the "optional" flag on both the authority
>>       side and the client.
> that must be written or parsed on every SvcParam.
>

Yes, the reverse of mandatory.
The "optional" flag would only be required if the particular SvcParam was
not in the corresponding "mandatory" list.
It would not be needed for things that are mandatory, so not always
present.
And not ever present for anything that is "automatically mandatory".
In the case of HTTPS, the only params that MIGHT have the optional flag
would be ip4hint, ip6hint, and ecn.
(The other types would not be eligible for the optional flag. This is the
intended meaning of "non-negotiable", as in, they can never have the
"optional" flag applied to them.)

> Additionally, for compatibility, it seems likely that the great majority
> of parameters will either be automatically mandatory (as specified in the
> mapping document) or optional (especially if they are introduced later), so
> making parameters mandatory unless marked otherwise seems like the wrong
> default.
>
>>
>>    - The binding tables then become lists of parameter sub-types that
>>    the specific binding uses, marked as optional-allowed or non-negotiable.
>>    The binding table incorporates all the MTI sub-types as well.
>>

That is consistent with my understanding. However, I would note that having
an IANA registry means not having to update any previous drafts. The IANA
tables can have columns that list appropriate sets of RFCs that make use of
a parameter, for example.

The main IANA table for DNS RRtypes is an example of such a table. It gets
updated by new RFCs (or sometimes IDs with early allocation).

There are a number of other tables for DNS, such as algorithms, EDNS
versions, flags, etc., Extended DNS Error Codes, etc.

> "implement" the alpn parameter by ignoring it.

So, no-default-alpn is automatically mandatory, but alpn is not? Unless
alpn is included in the mandatory list.
So, an HTTPS record could have "no-default-alpn" and "alpn", and the client
would not need to implement alpn, but at that point would have an alpn set
that is empty.
I'm not sure that's important...

> alternative formulation, I think you've shown that the complexity is

Flagged-optional is in an RR; optional is in (what I was supposing or
proposing to be) an IANA table indicating which types are permitted to be
flagged as optional, for any particular mapping.
The distinction between MTI and NN, is only relevant if there are any MTIs.
If there are no MTIs, then each parameter is either NN or optional.

It might help, at least for purposes of clarity and for the use case of the
mapping for HTTPS, to put all of the "always mandatory" elements as the
lowest-numbered values (i.e. 0 and 1).
It might be the case that new mappings don't consider those
always-mandatory.
Given that you are reserving a 16-bit range of values, it might be helpful
to group them into "always mandatory for some mappings". Except that which
ones are, might differ on new mappings.
Maybe put more structure into the 16-bit field, with e.g. a bit for "always
mandatory".
If a new mapping would otherwise have re-used a param, using a new param
with different "always mandatory" bit value might make it clearer across
those mappings (and allow mappings to check bits rather than going through
all the parameters.)

>
> I continue to prefer the current draft, as it provides the correct
> behavior in ordinary cases with simple inputs like
>
> 1 . alpn="h2,h3" ech=...
>

There are some client efficiencies that aren't obvious, I don't think.

Here is the same pair of records, using the two different encoding schemes:
;; pool HTTPS 1 h3pool alpn=h2,h3 ech="123..."
;; pool HTTPS 2 .      alpn=h2 ech="abc..."

;; pool TYPE66 1 h3pool 32768
;; pool TYPE66 2 . 32769
;; pool TYPE66 32768 alpn "h2"
;; pool TYPE66 32768 alpn "h3"
;; pool TYPE66 32768 ecn "123..." optional
;; pool TYPE66 32769 alpn "h2"
;; pool TYPE66 32769 ecn "abc..." optional

Suppose a client supports only a subset of the defined params.
The client can discard any params records with types it does not support.
If any of those params records are not optional, the "parent" record would
then be discarded as well.

Note that this representation actually breaks the ALPN into one record for
each list element, so there is no need for any escaping. Each list element
can be treated as a string, with or without any commas.
(This may help implementations on the intersection stuff between things the
client supports and what the ALPN offers, but I'm not sure if that's the
case and/or important.)

I'm hoping this feedback is useful, with or without the specific encoding
scheme.

I did a quick test implementation, and the wire overhead was not a
substantial increase, about 40%.
The simplicity on the zone file parsing is a useful benefit, as is the
ability to independently filter/flag parameters on the client side.
This will likely be more of a concern as more mappings get defined, IMHO.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 18 May 2021 13:56:05 -0700

> But it would need to understand the "default" ALPN of "http/1.1"?

That's essentially correct.  A client that only supports the default ALPN
has no use for the "alpn" SvcParam.

> make that more obvious.

Perhaps you can suggest a clarification?  We should definitely make the
terminology as clear as possible.

> entries or prior RFCs) aren't compatible with that intent?

My point is that SVCB mappings are IETF documents, complete with guidance,
normative language, deviations, exceptions, etc.  The summary table in
Appendix B is non-normative, and not connected to IANA in any way.  There
is no registry of mappings.

...

> The distinction between MTI and NN, is only relevant if there are any
> MTIs. If there are no MTIs, then each parameter is either NN or optional.
>
> It might help, at least for purposes of clarity and for the use case of
> the mapping for HTTPS, to put all of the "always mandatory" elements as the

Right; if we bake optional/mandatory-ness into the key itself, then not
only do we complicate the format; we also constrain future designs in ways
that are hard to foresee.

> Maybe put more structure into the 16-bit field, with e.g. a bit for
> "always mandatory".
>

It's certainly possible to imagine a format where we steal bits from the
TLV type field as flags for optional/mandatory.  The current approach was
chosen because it preserves the simple OPT-style TLV wire format, and
allows the mandatory/optional concepts to be separated entirely from the
wire-format and zone-file-format processing.

> ;; pool TYPE66 32769 ecn "abc..." optional

I find the second format much more difficult to read.  The relevant
information for each binding is spread across multiple lines in potentially
arbitrary order, bound together by identifiers that the reader must
remember.  It also seems like it would be much more work to write, and more
error-prone.

> The client can discard any params records with types it does not support.

I'm not sure what you're implying.  A client processing step that discards
some entries from the SvcParams map can do so regardless of what wire
format is in use.

> then be discarded as well.

Currently, this is covered under the definition of "compatible record" in
Section 7, and referenced in the description of client behavior: "A
ServiceMode RR is considered "compatible" with a client if the client
recognizes all the mandatory keys, and their values indicate that
successful connection establishment is possible.".

I don't think spreading the binding across multiple records makes this
easier to understand or implement.

> can be treated as a string, with or without any commas.

Yes.  However, note that this does not remove the need for nested escaping
in general.

This syntax makes every value into a set, even for keys that can only have
a single logical value, requiring additional validation to ensure that
single-valued keys stay single-valued.  It makes the "optional" flag an
independent property of each element of the set, creating the potential for
considerable complexity in handling differing optionality within a
value-set.

It also creates significant complexity for any future value that takes the
form of an ordered list.

> substantial increase, about 40%.

This seems like a considerable increase for a high-traffic record type.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 May 2021 17:35:39 -0400 (EDT)

On Tue, 18 May 2021, Ben Schwartz wrote:

> That's essentially correct.  A client that only supports the default ALPN has no use for the "alpn" SvcParam.

Does the "default ALPN" mean "no support for the ALPN extension" ? Or
does it mean "Supports ALPN with the default XXXX" ? If so, what is
XXXX?

> My point is that SVCB mappings are IETF documents, complete with guidance, normative language, deviations, exceptions,
> etc.  The summary table in Appendix B is non-normative, and not connected to IANA in any way.  There is no registry of
> mappings.

This really looks like you are creating an IANA registry for keywords
used within SVCB records.

> ;; pool HTTPS 1 h3pool alpn=h2,h3 ech="123..."

Why wouldn't this use:

 	pool HTTPS 1 h3pool alpn="h2,h3" ech="123..."

or:

 	pool HTTPS 1 h3pool alpn="h2,h3", ech="123..."

It is a little strange to me that some values are within quotes are
others are not. That really makes parsing (the presentation format)
harder.

> It also creates significant complexity for any future value that takes the form of an ordered list.

Security protocols are usually in the form of the initiator represents a
list (in whatever order) and the responder decides which it picks and
prefers from that set and uses that. Putting ordered lists in seems like
something the client in this case would mostly ignore as they will just
pretend not to support that is ordered at a higher preference in a list
in the DNS record?

But I did indicate already before that this RRtype is basically a
"security TXT" free flow record and it will surely lead to issues, yet
it seems unstoppable at this point anyway because of the milliseconds
for the advertisement auction gods.

> I did a quick test implementation, and the wire overhead was not a substantial increase, about 40%. 
> 

Well, you basically build a security protocol demultiplexer server HELLO
record that's not protected by a Finished message, whose protection
comes from DNSSEC but the people who want to run this at scale don't
want to do DNSSEC. As long as the message size is well within common
EDNS UDP packet size (with RRSIGs), then I think the size does not
matter.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Tue, 18 May 2021 15:06:27 -0700

On Tue, May 18, 2021 at 2:35 PM Paul Wouters <[email-masked]> wrote:

> > My point is that SVCB mappings are IETF documents, complete with
> guidance, normative language, deviations, exceptions,
> > etc.  The summary table in Appendix B is non-normative, and not
> connected to IANA in any way.  There is no registry of
> > mappings.
>
I should have given the numbers as well as percentages.
The original encoding for the response, including EDNS, was 191 bytes.
The new encoding (continuing to use 16-bit values for SvcPriority, all the
subtype values, and lengths, was 268 bytes.
Trimming the SvcPriority and subtype sizes to 8 bits (for comparison
purposes), but leaving lengths at 16 bits, the original encoding became 185
bytes
Trimming SvcPriority, subtype, and length on the new encoding (because
there won't be any single fields >250 bytes, assuming ALPN isn't insane),
becomes 249 bytes.

So, the differences are either 77 bytes, or 66 bytes. For a host with a
1Gbps link (not uncommon), this is about 0.5 microseconds of extra
serialization delay, or 1/2000th of a millisecond.
Editing zone files and checking their accuracy/consistency is more trivial
if the parsing is simpler and completely unambiguous. Most errors relate to
syntax, not semantics.
Providing a simple UI-like tool to either provide an input mechanism (to
allow the user to fill in fields, and produce the DNS records) is pretty
basic stuff, and reporting tools to output the associated elements (the
reverse of the UI tool) is also extremely simple.

Nothing on the wire will ever be a sorted list, modulo sorting of elements
within a record. The client will always have to sort records itself.
Sorting to do grouping is no different and no more complex than it is for
handling the SvcPriority (which it must).

And, in either encoding scheme, no matter how many records there are in the
(unsorted) RRset, the DNSSEC RRSIG will be the same size: one record per
ZSK.
All the records combined are less than 256B, so there is no difference in
efficiency for SHA256 (which requires padding).
So, basically, all of the differences are for practical purposes below the
noise floor.

The benefits should be considered on the merits proposed, not any issues
with the resulting wire format. IMNSHO.

Brian

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 19 May 2021 07:49:42 -0700

I wanted to chime in on this discussion as a client-side implementor who has already widely deployed support for SVCB/HTTPS.

The current format, where the parameters are structured as a list within a single RR, is certainly simpler and less error prone for processing. Much of the information contained as parameters within the SVCB RR are useful for higher-level “application” logic. Within our deployment, the DNS stub resolver daemon receives the RR and does the parsing, and passes up the parameters bundle as a blob that is more or less opaque, to the layer that handles actual connection processing (doing happy eyeballs, protocol selection).

Processing the content of SVCB parameters must be handled atomically: the ALPN, ECH config, and any other information must be handled clearly as a unit and not have any chance of being broken up. Lots of code is already based on processing RRs as chunks of data, and requiring anyone looking at the information to stitch the parameter list back together based on multiple RRs that must be in a particular order adds complexity and invites in bugs and errors.

I’d strongly encourage sticking with the wire image we’ve already been using and deploying. I like Erik’s suggestion that we solve the issues with parsing by putting more rules and constraints of the set of available characters, etc. 

Best,
Tommy

> On May 17, 2021, at 2:58 PM, Erik Nygren <[email-masked]> wrote:
> 
> 
> On Mon, May 17, 2021 at 5:36 PM Ben Schwartz <bemasc=[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Sat, May 15, 2021 at 12:48 PM Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Thu, May 13, 2021 at 10:25 AM Ben Schwartz <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Thu, May 13, 2021 at 12:51 AM Brian Dickson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz <[email-masked] <mailto:[email-masked]>> wrote:
> ... 
> Breaking the binding into pieces creates many new opportunities for error, such as having multiple TargetNames in a single binding.  It corresponds to a multimap datastructure instead of a standard map.  Every attribute of each binding would naturally be an unordered collection, which is a bad fit for attributes that are required to be singular, or an ordered list, or anything other than a set.
> ... 
> So, taking your observations about TargetName into account, and borrowing from the overloading of Priority to signal AliasMode, here's an alternative that I think addresses most of the concerns.
> Priority {AliasTarget | ServiceTarget | KeyName} {ServiceBindingPriorityValue | Value}
> where
> I find this format, with multiple lines and multiple integers per binding, much more difficult to read or write than the current draft, especially since the elements of each binding can potentially be spread across a zone file (perhaps by accident) in arbitrary order.
> 
> 
> I concur with Ben here.  Thank you for spelling out and proposing this alternative, but this seems much less usable
> and understandable by a typical user, either for zone publication or for reading diagnostic output from tools 
> Side-note: some precursors to SVCB and earlier discussions in the working group
> proposed using a standardized format such as CBOR for encoding the SvcParams but
> that approach was discarded as bringing in a bunch of its own baggage and being too
> An approach HTTP took was to define "Structured Field Values for HTTP" (rfc8941)
> be easier to parse, perhaps with a prefix to indicate that a string is base64 type?
> Are there other similar things that would keep the format similar to the existing

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 May 2021 13:34:40 -0700

On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <[email-masked]> wrote:

> I wanted to chime in on this discussion as a client-side implementor who
> has already widely deployed support for SVCB/HTTPS.
>
> The current format, where the parameters are structured as a list within a
> single RR, is certainly simpler and less error prone for processing. Much
> of the information contained as parameters within the SVCB RR are useful
> for higher-level “application” logic. Within our deployment, the DNS stub
> resolver daemon receives the RR and does the parsing, and passes up the
> parameters bundle as a blob that is more or less opaque, to the layer that
> handles actual connection processing (doing happy eyeballs, protocol
> selection).
>
> Processing the content of SVCB parameters must be handled atomically: the
> ALPN, ECH config, and any other information must be handled clearly as a
> unit and not have any chance of being broken up. Lots of code is already
> based on processing RRs as chunks of data, and requiring anyone looking at
> the information to stitch the parameter list back together based on
> multiple RRs that must be in a particular order adds complexity and invites
> in bugs and errors.
>
> I’d strongly encourage sticking with the wire image we’ve already been
> using and deploying.
>

Would it be accurate to say that as long as the wire format of both SVCB
and HTTPS do not change, your client implementation(s) would not be
impacted by any changes to zone file format?

I.e. you don't implement any server code, so what the zone format is does
not affect you, and how the wire format gets produced from the zone format
is not relevant to you?

Thank you for the details on how your client uses the wire format and the
way those impact the end client systems.

Brian

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 19 May 2021 14:12:50 -0700

> On May 19, 2021, at 1:34 PM, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> I’d strongly encourage sticking with the wire image we’ve already been using and deploying.
> 
> Would it be accurate to say that as long as the wire format of both SVCB and HTTPS do not change, your client implementation(s) would not be impacted by any changes to zone file format?
> 
> I.e. you don't implement any server code, so what the zone format is does not affect you, and how the wire format gets produced from the zone format is not relevant to you?

That’s correct. My main concern here is keeping the wire format consistent and simple. How the zone format file works is indeed something separate, and not something I have strong opinions on. Anything we can do to make the processing simple for both sides is great.

> 
> Thank you for the details on how your client uses the wire format and the way those impact the end client systems.

Absolutely! Happy to answer any further questions as well.

Best,
Tommy

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 May 2021 14:20:52 -0700

Given the request below to preserve the current wire format for both HTTPS
and SVCB, I think this raises some interesting options and questions:

   - My understanding of SVCB is that it is intended to be the "parent"
   type for both HTTPS and other future "mappings" over SVCB.
   - HTTPS is the first "instantiation" of an SVCB-compatible record type.

Given those two statements, would it not then make sense to separate out
the following:

   - HTTPS and SVCB zone file encoding schemes
      - HTTPS will be, in effect, "set in stone" by the whatever RFC
      defines it, and can have a zone file format that is tailored to the
      pre-defined parameters used for HTTPS (and excluding new HTTPS
parameters,
      modulo an update to an HTTPS RFC)
      - SVCB should not be set in stone, and be extensible, and thus may
      have need for a more flexible zone file format
   - Regardless of whether the zone file formats differ, splitting the
   current draft into two drafts (one for SVCB and one for HTTPS) makes a lot
   of sense.
      - Updates to HTTPS should not require touching SVCB
      - RR-specific RFCs are the norm
      - Decoupling them removes any artificial constraints on their
      respective zone file formats
      - Overly-generalized RRs was one of the major problems with SRV, and
      we should take advantage of that lesson. There is no benefit to burdening
      the zone file format of HTTPS with general-purpose machinery.
      - Referencing the wire format of SVCB reduces the unique elements of
      an HTTPS draft, allowing it to focus on the things that make HTTPS unique.
   - The decision to split them into two drafts should not in and of itself
   depend on what the specific contents of the HTTPS draft (i.e. details of
   that draft) are.
   - Even if the HTTPS zone file format does not change, there is still
   valid reason to split them into two drafts.
   - This also provides a sensible template for future SVCB-compatible
   drafts.
   - Any potential for burning a code point for the early allocation for
   HTTPS should not automatically impact the code point for SVCB. Splitting
   the draft into two formalizes that, and reduces any perceived issues with
   causing a code point to be consumed by revisions to either draft.

I'll follow up with some more specific suggestions about the zone file
format for HTTPS.
I don't really have major problems with SVCB, as the use case I'm primarily
concerned with is HTTPS.
Also, vendor/operator support for HTTPS and SVCB should also be decoupled.
It should be anticipated that some vendors will support HTTPS but not
support SVCB.

Brian

On Wed, May 19, 2021 at 1:34 PM Brian Dickson <[email-masked]>
wrote:

>> The current format, where the parameters are structured as a list within
>> a single RR, is certainly simpler and less error prone for processing. Much

---

From: Erik Nygren <[email-masked]>
Date: Wed, 19 May 2021 17:36:24 -0400

On Wed, May 19, 2021 at 5:12 PM Tommy Pauly <[email-masked]> wrote:

> That’s correct. My main concern here is keeping the wire format consistent
> and simple. How the zone format file works is indeed something separate,
> and not something I have strong opinions on. Anything we can do to make the
> processing simple for both sides is great.
>
>
Also as I understand it, changes that substantially change the semantics of
the records but preserving
the presentation format and wire format would also affect you?  In
particular, any shift from
a RR-per-service-binding to having service bindings span RRs in the RRset
would add significant
complexity to your client implementation as you've described?

Separately I've opened https://github.com/MikeBishop/dns-alt-svc/issues/324
to explore if there are ways we can simplify through character set
constraints.
In-particular, if we could get ALPN constrained to a set of token characters
(and similarly constrain future SvcParams that want to be value lists to
use
a limited subset of characters)  then some of the parsing concerns get
simpler.
I've mailed the TLS WG as they may not be willing to change how ALPN
registry
entries are handled in which case we'd still need a solution here.

Best, Erik

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 May 2021 21:50:18 +0000

Are these still just idle ideas you are tossing out (as you indicated earlier), or meant to be serious proposals? If the latter, what is the significant improvement over the current draft? I ask because it feels like you are suggesting moving the inherent complexity of the semantics of SCVB around, but not noticeably reducing it overall. Unless there is a significant reduction in complexity, I don't see the value of grinding on this further. (I say this as someone who is not happy with the current level of complexity of the semantics, but don't see a way to reduce it.)

--Paul Hoffman

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 19 May 2021 14:51:21 -0700

> On May 19, 2021, at 2:37 PM, Erik Nygren <[email-masked]> wrote:
> 
> 
> 
> 
> Also as I understand it, changes that substantially change the semantics of the records but preserving
> the presentation format and wire format would also affect you?  In particular, any shift from
> a RR-per-service-binding to having service bindings span RRs in the RRset would add significant

Correct. I’m saying that the wire format should remain as defined, as well as the contents and semantics—the single RR containing the various parameters needed to interpret a single service instance, with ALPN/ECH/Hints all together. Changing the way this service is spelled, such as breaking it into separate RRs, effectively breaks the wire format (since it is no longer intelligible as a single service). 
> to explore if there are ways we can simplify through character set constraints.
> (and similarly constrain future SvcParams that want to be value lists to use 
> a limited subset of characters)  then some of the parsing concerns get simpler.
> I've mailed the TLS WG as they may not be willing to change how ALPN registry

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 May 2021 15:00:45 -0700

On Wed, May 19, 2021 at 2:50 PM Paul Hoffman <[email-masked]> wrote:

> Are these still just idle ideas you are tossing out (as you indicated
> earlier), or meant to be serious proposals? If the latter, what is the
> significant improvement over the current draft? I ask because it feels like
> you are suggesting moving the inherent complexity of the semantics of SCVB
> around, but not noticeably reducing it overall. Unless there is a
> significant reduction in complexity, I don't see the value of grinding on
> this further. (I say this as someone who is not happy with the current
> level of complexity of the semantics, but don't see a way to reduce it.)
>
> --Paul Hoffman

It is meant to be a serious proposal.
The improvement is in the clarity and parse-ability of the HTTPS record in
zone file format, including reducing the complexity of the HTTPS-specific
semantics, without changing the actual wire format semantics or complexity
per se.

I'm working on the details of that, but it will necessarily be its own
work-in-progress. I hope to get something stable based on feedback... I
don't expect to get it 100% right on the first pass.

The first pass should hopefully illustrate the benefits at least, and
justify keeping list activity ongoing.

Brian

---

From: Eric Orth <[email-masked]>
Date: Wed, 19 May 2021 18:39:25 -0400

If you split presentation format records into one record per SvcParam, that
necessitates either changing the wire format to match or structuring the
presentation and wire formats fundamentally differently with a translation
to merge those records into a single record for the wire format.  What the
records are and the relations between them is a fundamental part of the
wire format.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 May 2021 16:00:28 -0700

> justify keeping list activity ongoing.

Here is a very very brief version of HTTPS (call it HTTPS RRTYPE version 2
pre-alpha-1, I suppose) ServiceForm RDATA (following the SvcPriority and
TargetName):

   - Make the "mandatory" field a derived (calculated) value, not an actual
   component of the zone format
   - no-default-alpn is a flag and excluded from the derived "mandatory
   set" (i.e. automatically mandatory) - no change, semantically
   - port is numeric, if present, and excluded from the derived "mandatory
   set" (i.e. automatically mandatory) - no change, semantically
   - ech, ipv4hint, and ipv6hint are string values (space separated list of
   values for *hint), and additionally marked as either mandatory or optional
   (syntax TBD) - conditionally added to "mandatory set"
   - alpn is a space-separated list of string values, and additionally
   marked as either mandatory or optional - conditionally added to "mandatory
   set".
   - The HTTPS RDATA itself is an ordered sequence of values, with
   placeholder empty values occupying the respective position, using the empty
   string ( "" ) if a parameter is not used
   - Thus, the RDATA is positional in nature, very similar to the SOA zone
   file format, and does not require any use of "key=" components at all
   - The sequence of values in the RDATA is "no-default-alpn", "port",
   "ech", "ipv4hint", "ipv6hint", "alpn"
   - The placement of alpn as the last element of the RDATA allows it to be
   a list of an arbitrary number of strings, rather than a singleton, which
   avoids the escaping characters issue.
   - The zone file format and parsing are deterministic and bidirectionally
   congruent.
   - The proposed marker(s) for either "optional" or "mandatory" are "~"
   for optional, and "+" for mandatory (similar to usage in SPF)

Note that, similar to the SOA record, most hand-editing of zone files would
involve copying the commented blank form, and changing whatever needs to be
specified according to the actual intention of the domain owner.

Here are some of the examples from the original draft, re-imagined with the
new zone file encoding.
NB: new zone format,  but representing identical corresponding wire formats
to the original examples:

alpn=h2,h3-19 mandatory=ipv4hint,alpn ipv4hint=192.0.2.1
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "" ; ech - not present
  "192.0.2.1" ; ipv4hint, mandatory (not marked with "~")
  "" ; ipv6hint - not present
  "h2" "h3-19" ; list of alpn values, mandatory (not marked with "~")
)

alpn="f\\\\oo\\,bar,h2"
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "" ; ech - not present
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "~foo,bar" "h2" ; list of alpn values, optional (marked with "~" on first
string meaning optional)
)

ipv6hint="2001:db8::1,2001:db8::53:1"
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "" ; ech - not present
  "" ; ipv4hint - not present
  "~2001:db8::1,2001:db8::53:1" ; ipv6hint, optional (per initial "~")
  "" ; alpn - not present
)

port=53
( "" ; no-default-alpn is "no" aka not-present
  "53" ; port
  "" ; ech - not present
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "" ; alpn - not present
)

(No parameters other than priority and target)
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "" ; ech - not present
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "" ; alpn - not present
)

alpn=h2,h3 ech="123..."
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "~123..." ; ech, not mandatory (marked with "~"
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "~h2" "h3" ; list of alpn values, optional (marked with "~")
)

alpn=h2 ech="abc..."
( "" ; no-default-alpn is "no" aka not-present
  "" ; port - not present
  "~abc..." ; ech, optional (not marked with "~")
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "~h2" ; (list of) alpn value(s), optional (marked with "~")
)

ech="111..." ipv6hint=2001:db8::1 port=1234
( "" ; no-default-alpn is "no" aka not-present
  "1234" ; port
  "111..." ; ech, optional (not marked with "~")
  "" ; ipv4hint - not present
  "~2001:db8::1" ; ipv6hint, optional (marked with "~")
  "" ; alpn - not present
)

port=8002 ech="..."
( "" ; no-default-alpn is "no" aka not-present
  "8002" ; port
  "~..." ; ech, optional (marked with "~")
  "" ; ipv4hint - not present
  "" ; ipv6hint - not present
  "" ; alpn - not present
)

Compactness in a zone file format is not a feature, it is (IMNSHO) a bug.
Clarity and unambiguous parsing, and round-trip (zone->wire->zone) identity
are attributes that should be major considerations.

Brian

---

From: Erik Nygren <[email-masked]>
Date: Wed, 19 May 2021 20:15:32 -0400

On Wed, May 19, 2021 at 7:01 PM Brian Dickson <[email-masked]>
wrote:

>
>
> On Wed, May 19, 2021 at 3:00 PM Brian Dickson <
>> The improvement is in the clarity and parse-ability of the HTTPS record
>> in zone file format, including reducing the complexity of the
>> HTTPS-specific semantics, without changing the actual wire format semantics
>> or complexity per se.
>>
>    - Make the "mandatory" field a derived (calculated) value, not an
>    actual component of the zone format
>    - port is numeric, if present, and excluded from the derived
>    "mandatory set" (i.e. automatically mandatory) - no change, semantically
>    - ech, ipv4hint, and ipv6hint are string values (space separated list
>    of values for *hint), and additionally marked as either mandatory or
>    optional (syntax TBD) - conditionally added to "mandatory set"
>    - Thus, the RDATA is positional in nature, very similar to the SOA
>    zone file format, and does not require any use of "key=" components at all
>    - The placement of alpn as the last element of the RDATA allows it to
>    be a list of an arbitrary number of strings, rather than a singleton, which
>    - The zone file format and parsing are deterministic and
>    bidirectionally congruent.
> Note that, similar to the SOA record, most hand-editing of zone files
> would involve copying the commented blank form, and changing whatever needs
> to be specified according to the actual intention of the domain owner.
>
> Here are some of the examples from the original draft, re-imagined with
> the new zone file encoding.
> NB: new zone format,  but representing identical corresponding wire
> formats to the original examples:
>
>   "~foo,bar" "h2" ; list of alpn values, optional (marked with "~" on
> first string meaning optional)
> )
>
Unless I'm missing something, this appears to remove the ability for
extensibility by adding additional
SvcParams in the future?  That is a major feature and "selling point" of
HTTPS and SVCB records
(and is even why "mandatory" exists) so I would not be in-favor of a
proposal that removes the ability for future extensibility.

Best, Erik

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 May 2021 17:35:08 -0700

On Wed, May 19, 2021 at 5:15 PM Erik Nygren <[email-masked]> wrote:

>
>
> On Wed, May 19, 2021 at 7:01 PM Brian Dickson <
>> Here is a very very brief version of HTTPS (call it HTTPS RRTYPE version
>> 2 pre-alpha-1, I suppose) ServiceForm RDATA (following the SvcPriority and
>> TargetName):
>>

I was under the impression that the extensibility is for the SVCB type, and
not strictly needed for HTTPS.
Adding new bindings is capable via unique combinations of the parameters,
including new (not yet defined) values for ALPNs.
Adding new TLVs to SVCB makes sense, as they would also require new mapping
and new RRTYPE values.
The mapping defined in whatever RFC specifies HTTPS (eventually) will be a
fixed thing.
IMHO, changing the RRTYPE by changing its presentation format (by adding
new SvcParameters) would require a new code point, as well as a new RFC.

Making HTTPS extensible is a big source of the problems in parsing, and
leaving SVCB extensible while making HTTPS non-extensible, solves that
problem.

If/when new parameters are needed, SVCB can be used while whatever updates
to HTTPS (or a successor to HTTPS with a new name) get handled by the IETF.

Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 20 May 2021 10:51:11 +1000

On Thu, May 20, 2021, at 10:35, Brian Dickson wrote:
> I was under the impression that the extensibility is for the SVCB type, 
> and not strictly needed for HTTPS.

It is absolutely needed for HTTPS.

I also want to add to what Tommy (P) said about deployment.  We've deployed the current wire format (that's what you get when you assign a codepoint people!)  Changes would have serious implications.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 May 2021 21:08:10 -0400 (EDT)

> I also want to add to what Tommy (P) said about deployment.  We've deployed the current wire format (that's what you get when you assign a codepoint people!)  Changes would have serious implication…

It looks like the early code point was assigned at 2020-06-30, at
draft-ietf-dnsop-svcb-https version 00. I think that might have been
premature, as that is technically at the same time the IETF _starts_
looking at it. This unfortunately makes it appear the IETF was only
to be used to rubberstamp it.

Documents are adopted as a starting point for discuccion, not as the
final code point definition with no wiggle room for change.

Not changing a document when concerns have been raised will have
the possibility of future "serious implications" that would in
fact be, more serious, as then we have an even larger install base
dealing with the problem.

This discussion should be around reasonable and secure wire and
presentation formats, not about "but we already deployed this".
It should surely be taken into account if changing at this point
gives enough benefits, but the idea of changing should not be
dismissed out of hand.

Paul

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 20 May 2021 11:14:19 +1000

> gives enough benefits, but the idea of changing should not be

Fair point.  I would request that if changes are made, then a new codepoint is used.  I think that is a reasonable request.  If that means that this codepoint is now burned and unusable; and that is a problem due to a scarce supply, then maybe more care is needed in future about early allocations (I agree that this one was premature).

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 May 2021 18:20:49 -0700

On Wed, May 19, 2021 at 6:15 PM Martin Thomson <[email-masked]> wrote:

> Fair point.  I would request that if changes are made, then a new
> codepoint is used.  I think that is a reasonable request.  If that means
> that this codepoint is now burned and unusable; and that is a problem due
> to a scarce supply, then maybe more care is needed in future about early
> allocations (I agree that this one was premature).
>

You are aware that we're at code point ~66 of 61000-ish possible
non-reserved values, right? (See
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
for the table and procedures.)
Burning a code point is not a concern in terms of resource exhaustion....

Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 May 2021 18:32:22 -0700

> It is absolutely needed for HTTPS.

I'm not saying I doubt you, but maybe you could explain what you think
would need to be added as an SvcParam, that would not be an ALPN, port,
ech, ipv4hint or ipv6hint?

Specifically that would need to be included as part of the one-lookup-DNS
value that is needed prior to making the TLS connection?

Is it one of those things that are "Well, we think we might need
something", or is it "We already know something we need"?

Is it something you know about and intend to deploy soon, like within the
next couple of years?

If not, how would SVCB NOT be reasonable to use instead of adding to the
HTTPS record?

(There's a reason I'm not suggesting making SVCB non-extensible, or
touching any aspect of the SVCB thing itself.)

Note that more ALPN values are supported, and how those are
defined/used/etc are really not relevant to the structure (wire format) of
the records (HTTPS or SVCB).

HTTPS needs transport, port number, name, and maybe some hints for IP
addresses, plus the new encrypted SNI.
I'm at a loss for what else could even be used for establishing a TLS
connection, in terms of anything/everything involved in TLS1.3?
The transport is signaled via ALPN, alternate ports can be used, addresses
are required, and name/SNI/ESNI/ECH are part of the TLS establishment.
Everything else is in-band within TLS itself (e.g. certificates) or
obtained from other sources (e.g. TLSA from DNS).

Is there something I'm missing that would be needed as part of the TLS
connection, from DNS ahead of time?

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 19 May 2021 18:35:04 -0700

On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> I like Erik’s suggestion that we solve the issues with parsing by putting
> more rules and constraints of the set of available characters, etc.
>

I don't get the impression that the TLS working group is likely to reach a
consensus to formally restrict the allowed characters in ALPN values.
However, there are currently no "problematic characters" in any of the
registered ALPN values, and it seems very likely to me that there never
will be.  With that gray area in mind, I have attempted to thread the
needle with the following proposed change:
https://github.com/MikeBishop/dns-alt-svc/pull/325/files.  The key sentence
is:

> So long as there are no registered protocol identifiers containing "," or
"\\", zone file implementations MAY disallow these characters instead of
implementing the `value-list` escaping procedure.

I'm sure this is no one's favorite option, but perhaps it is good enough to
enable us to move forward.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 20 May 2021 11:46:37 +1000

> something", or is it "We already know something we need"?

The former is definitely a factor.  Though you might reasonably say that defining another HTTPSv2 codepoint is feasible, that path doesn't scale particularly well.

For the latter, there is a fairly long list of things that don't have enough substance to be really defensible.

Off the cuff, we have discussed in TLS some options that would improve performance and reliability.  It's not clear whether those would fall into extension codepoints on the ECH configuration or the SVCB/HTTPS record.  In QUIC, we are discussing whether ALPN binds to QUIC versions and the implications of that.  Some versions of AltSvc designs relied on QUIC version indications there.  The outcome of that discussion might point toward needing more parameters on HTTPS for QUIC version negotiation.
 
I would have thought that the former would be sufficient in this case.  The fact that this space has been static an unmovable in the past has repressed a bunch of opportunities.  Locking this down now would return us to that state and would be exceedingly unwise (at least in my view).

Note that I say that as someone who generally tries to avoid creating extension points.  But I've been convinced that extensibility is perhaps the key feature that SVCB delivers.  I'm surprised to find that you think otherwise.

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 19 May 2021 21:49:48 -0400

All

I'd like to circle around as chair and call this discussion illuminating.
I do feel that there is rough consensus to keep with the current format.
The discussion here has gone down the path of wholesale redesign.

We call the WGLC closed for now. The authors have an updated document
to publish, and Ben's current suggestion can be taken into account.

Thanks for the discussion.   I plan on including this thread in the
shepherd's
writeup for the IESG to review.

tim

On Wed, May 19, 2021 at 9:35 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> https://github.com/MikeBishop/dns-alt-svc/pull/325/files.  The key
> sentence is:
>
> > So long as there are no registered protocol identifiers containing ","
> or "\\", zone file implementations MAY disallow these characters instead of
> I'm sure this is no one's favorite option, but perhaps it is good enough
> to enable us to move forward.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 19 May 2021 21:52:10 -0400 (EDT)

On Wed, 19 May 2021, Ben Schwartz wrote:

> So long as there are no registered protocol identifiers containing "," or "\\", zone file implementations MAY
> disallow these characters instead of implementing the `value-list` escaping procedure.

Sorry, an implementor cannot predict the future of the IANA registry. They
can't write code to confirm to this requirement other than NOT allowing
the MAY.

Even if they were silly enough to _first_ check the IANA registry before
parsing SVCB records, they would still have to write all the the parsing
code without CVE's for both cases, just in case the IANA registry would
gain these characters in the future.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 May 2021 12:14:47 +1000

> On 20 May 2021, at 11:52, Paul Wouters <[email-masked]> wrote:
> 

Or detect them and switch to key1=“…” instead of alpn=“…” when displaying
entry would need to be using keyXXXX format until the software was upgraded.

alpn=“h1\\,h2,h3” (or alpn=“h1\,h2,h3” I’m not sure where the consensus lies)
vs key1=“\005h1,h2\002h3"

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 May 2021 19:31:36 -0700

On Wed, May 19, 2021 at 7:15 PM Mark Andrews <[email-masked]> wrote:

> or "\\", zone file implementations MAY

I don't understand why any of the comma-escaping is needed at all, honestly.

RFC1035 has the definition of <character-string> encoding:
A bunch of characters without any internal spaces, or
A string beginning with " and ending with ", and anything else in between
except " which must be escaped.

So, alpn=<character-string>[,<character-string>]* is unambiguous.
Restricting the character-string format used
to the kind surrounded by quotes, removes any ambiguity regarding commas.
Parsers need to be sufficiently well built to not treat commas internal to
character-string values as special.

No escaping of anything other than double-quote characters within a single
value (an ALPN) is needed.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 May 2021 12:56:36 +1000

> On 20 May 2021, at 12:31, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> A string beginning with " and ending with ", and anything else in between except " which must be escaped.

Which doesn’t work in practice not the least because zone files where designed to be transferred between machines with different native character set encodings and different end of line conventions and the simplistic everything in between breaks in the real world.

example 0 iN TXT “abc
def”

will produce different wire encodings on a old mac, new mac and windows at the EOL could be encoded as CR, NL, or CR NL.  Add to that data entry where the native character set is not compatible with ASCII.

> So, alpn=<character-string>[,<character-string>]* is unambiguous. Restricting the character-string format used
> Parsers need to be sufficiently well built to not treat commas internal to character-string values as special.

It isn’t ambiguity that is the problem.  It’s working out which escape mechanism we are going to use.  You have just added a third escape mechanism with the above.

> No escaping of anything other than double-quote characters within a single value (an ALPN) is needed.
> 
> Brian
>

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 20 May 2021 12:37:07 +0200

Moin!

> addresses, plus the new encrypted SNI.
Well if we created HTTPS five years ago we would not have known about
encrypted client helo. The point of an extensible format is that you
can extend it beyond what you know now. And I am pretty sure there will
be development in the HTTPS arena.

For me mentally HTTPS is just a shortcut for
	_https.name IN SVCB …
so on the right side HTTPS and SVCB are the same and we should keep it
that way IMHO.

So long
-Ralf

---

From: Eric Orth <[email-masked]>
Date: Thu, 20 May 2021 13:59:44 -0400

A big selling point behind why we have client implementers planning to
query HTTPS records is the expectation that this will be the only query
type we will need to add and that it can be extended to handle any future
information we need for establishing HTTPS connections (and we want
mechanisms to be able to add stuff in the future to keep improving HTTPS
connection behavior).  It is not practical to add too many additional DNS
queries to make web requests, and nobody wants a
deprecation/new-SVCB-based-record-type cycle every time we need to add
something.  So in the end, I do not expect HTTPS would see much adoption
without the extensibility.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 20 May 2021 11:09:34 -0700

> without the extensibility.
Okay, so the takeaway from that is whatever is done to improve the ability
to parse the records, should include the extensibility.
(That limits the amount that can be done to improve parsing and to make it
more DNS-like, but there is still room for improvement, IMHO.)

I'll think about how that can be done (improving parsing, not
extensibility, i.e. any proposal(s) I make will be based off a baseline
which will be the current format.)

Brian

---

From: "Ralf Weber" <[email-masked]>
Date: Thu, 20 May 2021 20:29:40 +0200

Moin!

> without the extensibility.
I fully agree. The point I was making is that ECH sort of already is an
extension that were not in the original draft and there may be other
Enhancements in the future.

So long
-Ralf
——-
Ralf Weber

---

From: Dick Franks <[email-masked]>
Date: Thu, 20 May 2021 20:38:25 +0100

> Which doesn’t work in practice not the least because zone files where designed to be transferred between machines with different native character set encodings and different end of line conventions…
example.    0    IN    TXT    \226\128\156abc
unable to parse RR string at blib/lib/Net/DNS/ZoneFile.pm line 523.
  file MarkA.txt line 2
  at test.pl line 14.

QNED, or is Mark winding us up!

> It isn’t ambiguity that is the problem.  It’s working out which escape mechanism we are going to use.  You have just added a third escape mechanism with the above.

In an earlier post I rashly promised to provide some words, which I
will do in the next couple of days.

--Dick

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 May 2021 11:16:11 -0700

> Enhancements in the future.

I think the handling of presentation formats and wire formats leaves much
to be desired.

However, the handling of future extensions is not (IMHO) currently usable
via the existing proposed mechanism.

The discussion about "what if ECN needed to be added later" got me thinking
about the issue.

I think there is a need for something similar to RFC3597, except for fields
in a record rather than a BLOB for the record itself.
RFC3597 is fine for an RRTYPE with only one RDATA element/structure, but
not for complex RRs.
So, this problem on sub-field encodings has arisen from ignoring RFC5507
(regardless of why it has been ignored).

There is a pertinent question about any method of addressing this gap:
should it be limited to SVCB (part of this draft), or its own thing?
I can see valid arguments either way.
If it is a standalone thing, that would seem to encourage, rather than
discourage, ignoring 5507.
If it is part of SVCB, it would not be expected that an authority server
would support that outside of supporting SVCB/HTTPS.
Possibly, it could be seen as an enhancement to 3597, in which case the
standalone should definitely point the reader at 5507.

Here's a short list of things I think such a scheme should have:

   - A set of defined presentation-format:wire-format (bidirectional)
   mappings
   - A method of applying a label to a key number
   - For backward compatibility to any existing implementations, these
   should both be optional, with the existing mapping as the default
   - The set of mappings should be independent of the key numbers to which
   they are applied
   - The set of mappings should be a superset of any mappings used in SVCB
   already, and should include other well-known mappings
   - There should be a mapping type for "flag" where the existence of the
   keyNNN without any data is supported for both presentation and wire formats.
   - This mapping should be used for all of the existing SVCB parameter
   types that already exist, to make implementation much easier and consistent

Here's what I think would work:

   - keyNNNN:label:mapping=value

with the following alternate formats:

   - label=value -- requires label be understood by the server, including
   both the corresponding key number and mapping
   - keyNNNN::mapping=value -- no label included
   - keyNNNN=value -- no label included, default generic mapping
   - keyNNNN:label=value -- label available, default generic mapping

For purposes of examples, here are some suggested mappings:

   - TLVSorted - space-separated sequence of name=value mapped items; wire
   format is a sorted sequence of 16-bit key, 16-bit length, and wire-format
   value defined for the corresponding key (sorted by key number)
      - SVCB and HTTPS formats are TLVSorted
      - Presentation formats do not need to be sorted
   - uint16 - single integer with no leading zeros, maps to 16-bit unsigned
   value, must be a singleton
   - uint16SortedList - comma-separated list of integers between 0-65535,
   maps to a sorted sequence of 16-bit unsigned values
   - base64 - base-64 encoded blob, maps to whatever binary it decodes to,
   must be a singleton
   - flag - has no value in presentation format, has no data in wire format
   (implicitly a singleton)
   - ipv4list - one or more IPv4 addresses in acceptable standard format
   for an A record - if multiple, space separated and double-quote delimited;
   maps to a sequence of IPv4 addresses (A record wire encoding)
   - ipv6list - one or more IPv6 addresses in acceptable standard format
   for an AAAA record - if multiple, space separated and double-quote
   delimited; maps to a sequence of iPv6 addresses (AAAA record wire encoding)
   - CSV - one or more strings, separated by commas, enclosed in double
   quotes, as follows:
      - inside quotes is encoded as the subset of printable-ASCII
      characters in the range of decimal 32 to decimal 126 with escaped
      (backslash) double-quote, escaped escape (double backslash), and also
      permitting other 8-bit values as escaped-decimal values \DDD
      - maps to sequence of (length | value) where each length is uint8 and
      length(value) is between 1 and 255 inclusive.
      - mapped value of one string from the list is the contents of the
      substituted string (e.g. with escape substitutions performed) without the
      enclosing quotes
   - FQDN - a valid domain name; maps to wire-encoding for a domain name
   - The defined field mappings may be added to by <TBD> process (RFC
   required, Standards Action, other?)

Here's what I think the appropriate key/label/mapping should be for the
initial record and SvcParams:

   - SVCB/HTTPS Resource Record is:
      - SvcPriority (uint16)
      - TargetName (FQDN)
      - SvcParams (TLVSorted)
   - SvcParams table keynum/label/mapping:
   - 0/mandatory/uint16SortedList
   - 1/alpn/CSV
   - 2/no-default-alpn/flag
   - 3/port/uint16
   - 4/ipv4hint/ipv4list
   - 5/ech/base64
   - 6/ipv6hint/ipv6list

The specifics for alpn and CSV are somewhat novel, I realize, but I think
they are sufficiently unambiguous and well-defined to enable 2-way mappings
of arbitrary binary blobs of up to 255 characters, so can handle any
potential ALPN value.
Thus, the example used of foo\\,bar,h2 would be, as a CSV, "foo,bar","h2",
and in wire format would be "\x00 \x11 \x07 foo,bar \x02 h2".

Brian

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 21 May 2021 14:57:40 -0400

All

The WGLC has been closed.

There will also be an IETF LC to raise concerns.

tim

On Fri, May 21, 2021 at 2:17 PM Brian Dickson <[email-masked]>
wrote:

> The discussion about "what if ECN needed to be added later" got me
> thinking about the issue.
>
> I think there is a need for something similar to RFC3597, except for
> fields in a record rather than a BLOB for the record itself.
>    - The set of mappings should be independent of the key numbers to
>    which they are applied
>    - The set of mappings should be a superset of any mappings used in
>    SVCB already, and should include other well-known mappings
>    - TLVSorted - space-separated sequence of name=value mapped items;
>    wire format is a sorted sequence of 16-bit key, 16-bit length, and
>    wire-format value defined for the corresponding key (sorted by key number)
>    - uint16 - single integer with no leading zeros, maps to 16-bit
>    unsigned value, must be a singleton
>    - base64 - base-64 encoded blob, maps to whatever binary it decodes
>    to, must be a singleton
>    - flag - has no value in presentation format, has no data in wire
>    format (implicitly a singleton)
>       - maps to sequence of (length | value) where each length is uint8
>       and length(value) is between 1 and 255 inclusive.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 May 2021 12:46:54 -0700

Context: there is a general problem on sub-field encodings (i.e. which has
arisen from new drafts failing to observe RFC5507's recommendations.)
An example use case would be adding extensions to any RRTYPE which uses TLV
wire format, and for which no semantically-meaningful encoding of new types
within the RRTYPE RDATA in presentation format exists.

   - A set of defined presentation-format <-> wire-format (bidirectional)
   transformations
   - The optional inclusion of a type code (the T in TLV) if the resource
   record format is TLV
   - A method of applying a label to a field (for use by user-interfaces,
   or for hand-edited zone file clarity)

Such a scheme would facilitate more-complex RRTYPEs, and be more
zone-file-friendly than RFC3597

keyNNNN:label:mapping=value

label=value -- requires label be understood by the server, including both
the corresponding key number and mapping

label:mapping=value -- if the LHS does not begin with "keyNNNN", it is not
a TLV encoding in wire format, only a field value encoding

keyNNNN::mapping=value -- no label included
keyNNNN=value -- no label included, default generic mapping
keyNNNN:label=value -- label available, default generic mapping

The presentation format of "value" would itself be subject to the rules
specified by the "mapping" used.

For backward compatibility to any existing implementations, the
specification of "keyNNNN" and "mapping" should both be optional, with the
existing mapping as the default.
This would facilitate migration of zone files between implementations which
are "extension-aware" and "extension-unaware" for any given extension of an
RRTYPE

uint16 - single integer with no leading zeros, maps to 16-bit unsigned
value, must be a singleton

uint16List - comma-separated list of integers between 0-65535, maps to the
same (unsorted) sequence of 16-bit unsigned values; TLV length specifies
total length; use in non-TLV context requires a uint16 length

uint16SortedList - comma-separated list of integers between 0-65535, maps
to a sorted sequence of 16-bit unsigned values; TLV length specifies total
length; use in non-TLV context requires a uint16 length
base64 - base-64 encoded blob, maps to whatever binary it decodes to, must
be a singleton

base64List - list of base-64 encoded items, comma separated in presentation
format; a sequence of 16-bit length/value pairs in wire format; TLV length
specifies total length; use in non-TLV context requires a uint16 length

flag - has no value in presentation format, has no data in wire format as a
TLV (implicitly a singleton), or a uint16 representation of 0 or 1 in the
non-TLV use case

ipv4 - an IPv4 address in the same format as an A record (both presentation
and wire formats)

ipv4list - one or more ipv4 values - if multiple, space separated and
double-quote delimited; maps to a sequence of IPv4 addresses (A record wire
encoding); TLV length specifies total length; use in non-TLV context
requires a uint16 length
ipv6 - an IPv6 address in the same format as an AAAA record (both
presentation and wire formats)
ipv6list - one or more IPv6 addresses  - if multiple, space separated and
double-quote delimited; maps to a sequence of iPv6 addresses (AAAA record
wire encoding);  TLV length specifies total length; use in non-TLV context
requires a uint16 length
CSV - one or more strings, separated by commas, enclosed in double quotes,
as follows:

inside quotes is encoded as the subset of printable-ASCII characters in the
range of decimal 32 to decimal 126 with escaped (backslash) double-quote,
escaped escape (double backslash), and also permitting other 8-bit values
as escaped-decimal values \DDD
maps to sequence of (length | value) where each length is uint8 and
length(value) is between 1 and 255 inclusive.
mapped value of one string from the list is the contents of the substituted
string (e.g. with escape substitutions performed) without the enclosing
quotes
TLV length specifies total length; use in non-TLV context requires a uint16
length

FQDN - a domain name; maps to wire-encoding for a domain name

Discussion/feedback is welcome.
If there is interest, I will write this up as an ID.

Brian

---

From: Dick Franks <[email-masked]>
Date: Sat, 22 May 2021 09:58:17 +0100

All,

Please find attached the promised words to resolve the conflict
between current draft and RFC1035.

This is presented as a context diff.

Dick Franks
________________________

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 22 May 2021 16:06:19 +0000

> This is presented as a context diff.

Where do we find the original Markdown file so we can evaluate the diff?

--Paul Hoffman

---

From: Dick Franks <[email-masked]>
Date: Sat, 22 May 2021 17:57:48 +0100

> Where do we find the original Markdown file so we can evaluate the diff?

https://github.com/MikeBishop/dns-alt-svc

--Dick

---

From: "Ralf Weber" <[email-masked]>
Date: Sun, 23 May 2021 10:45:30 +0200

Moin!

> I think the handling of presentation formats and wire formats leaves much
As others said the wire format is a pretty standard TLV format, so I don’t
think there is a change needed as this sort of format is well understood.
I’m also confident that zone file presentation can be sorted out for regular
uses and we always have the generic \nnn escaping for the more complicated
ones.

> RFC3597 is fine for an RRTYPE with only one RDATA element/structure, but
RFC3597 just works fine with HTTPS. Most people have been using it for some
time now, unless they have recursor already supports HTTPS/SVCB. IMHO HTTPS
has shown that RFC3597 works today as there were only minor effects on
rolling out a new resource record. I think Google did an additional test
with an unregistered RRType and came to the same conclusion, but I don’t
have the details at hand.

> (regardless of why it has been ignored).
The only mention of that is in comparison to TXT records people used for
e.g SPF and other things. The specific advise there is only if your record
size is so big that it exceeds general DNS packet size make it a pointer
instead of stuffing it in the resource record. The generic advice of RFC5507
is to create a real resource record type instead of using TXT, and IMHO
this draft follows this advice (both the RR and size recommendations).

So long
-Ralf
——-
Ralf Weber

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 24 May 2021 10:52:36 -0400

For those who prefer Github's UI, I've posted Dick's diff to a branch
commit in our repository [1].

The diff contains a number of editorial suggestions, such as removing use
of ABNF, which we can consider separately.  The key substantive change, as
discussed earlier in this thread, is to make comma-escape handling for
value lists happen during character-string escape parsing, instead of
afterward.

In the implementations I've worked on so far, this change would be highly
inconvenient to implement, as it conditionally modifies the core
character-string parsing loop that has thus far been entirely
RR-type-independent and shared by all zone-file parsing contexts.

The only way I can see to accommodate both of these implementation
perspectives is to allow implementors to avoid the offending special case,
which, as I've noted before, is not currently needed, and may never be
needed.  I have proposed a change [2] that would add this option (now
updated to avoid conditioning requirements on the IANA registry, in
response to feedback from Paul Wouters).

--Ben

[1]
https://github.com/MikeBishop/dns-alt-svc/commit/5d3d651230de06adce10625d0dfb70ce8e938a39
[2] https://github.com/MikeBishop/dns-alt-svc/pull/325/files

---

From: Dick Franks <[email-masked]>
Date: Mon, 24 May 2021 20:45:37 +0100

On Mon, 24 May 2021 at 15:52, Ben Schwartz <[email-masked]> wrote:
>
> For those who prefer Github's UI, I've posted Dick's diff to a branch commit in our repository [1].
Thanks

>
> The diff contains a number of editorial suggestions, such as removing use of ABNF, which we can consider separately.  The key substantive change, as discussed earlier in this thread, is to make comma-escape handling for value lists happen during character-string escape parsing, instead of afterward.
>
The ABNF defines the acceptable characters as a range of ASCII codes.
This ignores the inconvenient fact that zone files can be written
using some other non-ASCII codeset.
The character codes for 'a'...'z' will be different, and in the case
of EBCDIC not even contiguous.

The key substantive change is to make the draft conform to the
long-standing escape conventions enshrined in RFC1035.

> In the implementations I've worked on so far, this change would be highly inconvenient to implement, as it conditionally modifies the core character-string parsing loop that has thus far been entirely RR-type-independent and shared by all zone-file parsing contexts.
>
> The only way I can see to accommodate both of these implementation perspectives is to allow implementors to avoid the offending special case, which, as I've noted before, is not currently needed, and may never be needed.  I have proposed a change [2] that would add this option (now updated to avoid conditioning requirements on the IANA registry, in response to feedback from Paul Wouters).

For this to qualify as an issue sufficiently general to merit special
consideration in the spec, then it would need to be an insurmountable
obstacle encountered by every implementation.
BIND, NSD, PowerDNS, and Net::DNS are well able to deal with escapes
as described in RFC1035, all of them conspicuous counter-examples to
any argument that special treatment of double escapes is an essential
requirement.

Repeating the same fatuous argument ad nauseam will not make the issue go away.

--Dick

>
> --Ben
>
> [1] https://github.com/MikeBishop/dns-alt-svc/commit/5d3d651230de06adce10625d0dfb70ce8e938a39

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 24 May 2021 17:13:38 -0400

On Mon, May 24, 2021 at 3:46 PM Dick Franks <[email-masked]> wrote:
...
> any argument that special treatment of double escapes is an essential

I continue to believe that this draft is strictly within the RFC1035
escaping procedure, whereas you are proposing a change to RFC1035
escaping.

I previously mentioned NAPTR as an example of a record type that uses
multilayer escaping, and does not attempt to integrate
datatype-specific escaping rules into the char-string parser.  The URI
RR type is another example.  Thus, foo://example/%\ is rendered as
"foo://example/%25\\", and not as "foo://example/\%\\".