Subject: [DNSOP] HTTPS and SVBC key names.

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Jul 2020 11:24:30 +1000

Can we please have a length limit on key names?  At the moment they could be a billion characters long as they don’t go over the wire.
-- 
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: Thu, 9 Jul 2020 21:40:08 -0400

How about 255 characters?

On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews <[email-masked]> wrote:

> Can we please have a length limit on key names?  At the moment they could
> be a billion characters long as they don’t go over the wire.
> --
> Mark Andrews, ISC
> PHONE: +61 2 9871 4742 <+61%202%209871%204742>              INTERNET:
> [email-masked]
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Erik Nygren <[email-masked]>
Date: Thu, 9 Jul 2020 22:17:54 -0400

Or 64?

- Erik

     [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 15 Jul 2020 13:07:25 -0400

How about 2 or 10 ?
why do  the names to need to be long ?

Olafur

On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren <[email-masked]> wrote:

>>> Can we please have a length limit on key names?  At the moment they
>>> could be a billion characters long as they don’t go over the wire.
>>> --
>>> Mark Andrews, ISC

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com

---

From: Erik Nygren <[email-masked]>
Date: Wed, 15 Jul 2020 13:16:07 -0400

We landed on 63 in the draft version we just published  (to align with max
label lengths).
There's no reason they *need* to be short as they are just in presentation
form, so their length
comes down to usability and finding the right words.  The longest currently
is 15 and it would
be better to avoid future ones needing to be artificially constrained.  Is
there a reason we'd
want to decrease this (eg, to 31)?

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 15 Jul 2020 13:34:02 -0400

DoU i.e. DNS over UDP packet size impact,

Olafur

On Wed, Jul 15, 2020 at 1:16 PM Erik Nygren <[email-masked]> wrote:

> comes down to usability and finding the right words.  The longest
> currently is 15 and it would

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 15 Jul 2020 10:40:46 -0700

This is only the presentation format—in wire format, these are alway 2-byte integers. Thus, there isn’t any effect on packet size.

Thanks,
Tommy

> On Jul 15, 2020, at 10:34 AM, Ólafur Guðmundsson <olafur=[email-masked]> wrote:
> 
> On Wed, Jul 15, 2020 at 1:16 PM Erik Nygren <[email-masked] <mailto:[email-masked]>> wrote:
> We landed on 63 in the draft version we just published  (to align with max label lengths).
> There's no reason they *need* to be short as they are just in presentation form, so their length
> comes down to usability and finding the right words.  The longest currently is 15 and it would
> be better to avoid future ones needing to be artificially constrained.  Is there a reason we'd
> On Wed, Jul 15, 2020 at 1:07 PM Ólafur Guðmundsson <[email-masked] <mailto:[email-masked]>> wrote:
> How about 2 or 10 ? 
> On Thu, Jul 9, 2020 at 10:18 PM Erik Nygren <[email-masked] <mailto:[email-masked]>> wrote:
> Or 64?  
> 
> 
> 
> - Erik
> 
> On Thu, Jul 9, 2020, 9:40 PM Ben Schwartz <bemasc=[email-masked] <mailto:40google.com@dmarc..ietf.org>> wrote:
> On Thu, Jul 9, 2020 at 9:25 PM Mark Andrews <marka@isc..org <mailto:[email-masked]>> wrote:
> Can we please have a length limit on key names?  At the moment they could be a billion characters long as they don’t go over the wire..
> -- 
> Mark Andrews, ISC
> PHONE: +61 2 9871 4742 <tel:+61%202%209871%204742>              INTERNET: [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> 
> 
> -- 
> www.cloudflare.com <http://www.cloudflare.com/> blog.cloudflare.com <http://blog.cloudflare.com/>
> 
> -- 
> www.cloudflare.com <http://www.cloudflare.com/> blog.cloudflare.com <http://blog.cloudflare.com/>_______________________________________________
> DNSOP mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: Brian Dickson <[email-masked]>
Date: Wed, 15 Jul 2020 12:02:03 -0700

> want to decrease this (eg, to 31)?

These key names are table entries in an IANA table, and never go over the
wire.
So, while it might be a reasonable design choice to limit the character set
to match DNS labels, i.e. US ASCII, that's not technically a requirement.
I'm not suggesting doing otherwise, but, it should at least be called out
as a conscious decision.
Maybe an alternative solution would be "any valid A-label", which would
potentially support UTF table entries encoded with puny-code?

As for length, as long as it is long enough to encode "bikeshed-colour", I
don't really care. :-)

Brian

---

From: Dick Franks <[email-masked]>
Date: Thu, 16 Jul 2020 09:06:28 +0100

Beefed-up example from 5.3, where we know neither the key name nor how to
interpret the value:

    foosvc.example.net. 3600 IN SVCB    \# 9 000100ff350002beef
  ; 1 . key65333=...

Presentation format?

Also, why do (key,value) pairs need to be in ascending order on the wire,
but can be in any order in the presentation format?

Dick Franks
____________________

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 16 Jul 2020 08:31:45 -0400

>     foosvc.example.net. 3600 IN SVCB    \# 9 000100ff350002beef

Should this say "TYPE64" instead of SVCB?  Apart from that, this looks right

> Presentation format?

key65333=\190\239

> but can be in any order in the presentation format?

The presentation format is optimized for humans and the wire format is
optimized for machines. In particular, when using the named keys it's not
obvious what the numeric ordering is, so keeping them in order when editing
a zone file by hand would be hard.

---

From: Dick Franks <[email-masked]>
Date: Thu, 16 Jul 2020 20:49:51 +0100

> Should this say "TYPE64" instead of SVCB?  Apart from that, this looks

No.  The IANA registry was updated on June 30 and perl Net::DNS::Parameters
is generated from the XML. It will be in the next Net::DNS release.

> key65333=\190\239

If this is a string, should this say?    key65333="\190\239"

> a zone file by hand would be hard.

That does not answer the question.
What is the reason for the keys to be in ascending order?

There is also some inconsistency in the use of quotes.

2.3 has:

  svc4.example.net.  7200  IN SVCB 3 svc4.example.net. (
       alpn="bar" port="8004" echconfig="..." )

2.5.2 has:

  svc2.example.net. 7200  IN HTTPS 1 . port=8002 echconfig="..."

Is the port value an integer or a string, with the quotes being optional?

Is the wire format a character string to be interpreted as an integer
by the client,
or a packed integer in network byte order?

--Dick

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 16 Jul 2020 16:17:30 -0400

On Thu, Jul 16, 2020 at 3:50 PM Dick Franks <[email-masked]> wrote:

>>> Beefed-up example from 5.3, where we know neither the key name nor how
>>> to interpret the value:
>>>
> No.  The IANA registry was updated on June 30 and perl
> Net::DNS::Parameters is generated from the XML. It will be in the next
> Net::DNS release.
>
>
>
>> Presentation format?
>>>
>>
>> key65333=\190\239
>>
>

Quotes are optional, as with <character-string>.  Quotes are only required
if the value contains whitespace.

>
>>> Also, why do (key,value) pairs need to be in ascending order on the
>>> wire, but can be in any order in the presentation format?
>>>
>>

I think this was motivated primarily by a general belief that unnecessary
degrees of freedom should be removed, to minimize variation between
implementations.  Every variation is a chance for surprises, from buggy
interactions to information leakage.  It also potentially simplifies
validation of a record by the recipient.

> The quotes are always optional, except when the presentation value
contains whitespace, regardless of the data type.

> Is the wire format a character string to be interpreted as an integer by the client,
> The port wire format value is a packed integer in network byte order.

---

From: Dick Franks <[email-masked]>
Date: Mon, 20 Jul 2020 19:39:16 +0100

> if the value contains whitespace.

I was trying to establish if the quotes indicated the data type.  Clearly
not.

>>> a zone file by hand would be hard.
  blog.cloudflare.com. 300 IN HTTPS ( 1  .

key1=\005\104\051\045\050\057\005\104\051\045\050\056\005\104\051\045\050\055\002\104\050
     key4=\104\018\026\046\104\018\027\046

key6=\038\006\071\000\000\000\000\000\000\000\000\000\104\018\026\046\038\006\071\000\000\000\000\000\000\000\000\000\104\018\027\046
     )

"optimized" is not the word which springs to this human's mind.
IMHO, tarted up RFC3597 format is easier to read.

Example:

    use Net::DNS;

    my $rr = new Net::DNS::RR <<'END';
    example.net.        300     IN      HTTPS   1 target.example.net.
        mandatory=key0,key1,alpn,no-default-alpn,key99  ; with duplications
and other sins
        alpn=h3-29,h3-28,h3-27,h2
        no-default-alpn
        port=1234
        ipv4hint=192.0.2.1,192.0.2.2
        echconfig=base64string
        ipv6hint=2001:DB8::1,2001:DB8::2
    END

    $rr->print;

produces:

    example.net.    300     IN      HTTPS   ( \# 126 0001
        06746172676574076578616d706c6503 6e657400 ; target.example.net.
        0000 0004 00010002
        0001 0015 0568332d32390568332d32380568332d 3237026832
        0002 0000
        0003 0002 04d2
        0004 0008 c0000201c0000202
        0005 0009 6dab1eeb8b2dae29e0
        0006 0020 20010db8000000000000000000000001
20010db8000000000000000000000002
        )

Observations and complaints gratefully received.

--Dick

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 20 Jul 2020 17:54:31 -0400

> "optimized" is not the word which springs to this human's mind.

The unknown-key format is designed more for authoring than reading.  As an
author, it works somewhat better than your example.  For instance, your
key1 could be written as

key1=\005h3-29\005h3-28\005h3-27\002h2

That seems more intelligible than hex or base64.

Also, your key4 here pretty clearly shows the IPv4 addresses 104.18.26.46
and 104.18.27.46.

In short, the unknown-key format is fairly usable for authoring fields
whose values are plain text or numeric octets, since a human author can
choose escape codes or ASCII characters as appropriate.  A renderer (by
definition) has no idea what the contents mean, so it can work well for
plain text or numeric octets but not both.

With the addition of comments for the recognized keys and fields, I think
you're probably right.  However, when authoring a zone file I would hate to
have to use RFC 3597 hex for the whole record just to add one key that my
parser doesn't support yet.  Also, if most future keys turn out to have
ASCII plaintext values (e.g. URLs), an unknown key renderer that uses ASCII
symbols where possible might turn out to work quite well.

Example:
>         mandatory=key0,key1,alpn,no-default-alpn,key99  ; with
> duplications and other sins
> <(323)%20702-6832>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Jul 2020 09:25:12 +1000

> On 21 Jul 2020, at 04:39, Dick Franks <[email-masked]> wrote:
> 
> 
> Quotes are optional, as with <character-string>.  Quotes are only required if the value contains whitespace.
> 
> I was trying to establish if the quotes indicated the data type.  Clearly not.
>  
> The presentation format is optimized for humans and the wire format is optimized for machines. In particular, when using the named keys it's not obvious what the numeric ordering is, so keeping them in order when editing a zone file by hand would be hard.
> 

Well the presentation form clearly is designed for printable ASCII to be rendered as ASCII.

>         mandatory=key0,key1,alpn,no-default-alpn,key99  ; with duplications and other sins

Which is a interesting conversion of "mandatory=key0,key1,alpn,no-default-alpn,key99”. I would expect the parser to reject the record as mandatory contains “key0” in the list.  I would also expect the parser to reject the record as there is no “key99” in the record.  I would never expect the parser to strip out keys listed in mandatory just because they are not present in the rest of the record.

>         0006 0020 20010db8000000000000000000000001 20010db8000000000000000000000002
>         )
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 21 Jul 2020 09:47:48 +1000

> On 17 Jul 2020, at 05:49, Dick Franks <[email-masked]> wrote:
> 

Ascending order allows the client to stop processing when it has processed all the keys it knows about.  If you have a unknown mandatory key listed you skip the record.

Also once you have the keys in order duplicate key detection is easy as is checking that all mandatory keys are present.

---

From: Dick Franks <[email-masked]>
Date: Wed, 22 Jul 2020 18:26:21 +0100

> Well the presentation form clearly is designed for printable ASCII to be

Except for the inconvenient fact that Net::DNS also works on OS390 which
speaks EBCDIC.

> >         ...

> Which is a interesting conversion of
> "mandatory=key0,key1,alpn,no-default-alpn,key99”. I would expect the parser
> to reject the record as mandatory contains “key0” in the list.  I would
> also expect the parser to reject the record as there is no “key99” in the
> record.  I would never expect the parser to strip out keys listed in
> mandatory just because they are not present in the rest of the record.
>

Good idea.
I was only raising these exceptions on received packets, but the same tests
are reasonable for freshly created RR.

--Dick

---

From: Dick Franks <[email-masked]>
Date: Wed, 22 Jul 2020 21:28:20 +0100

On Mon, 20 Jul 2020 at 22:54, Ben Schwartz <[email-masked]> wrote:

> key1=\005h3-29\005h3-28\005h3-27\002h2

It is not as easy as you might think.  This all needs to work on EBCDIC and
UTF8 platforms.
I plan to kick the problem into the long grass for now.

Am I correct in thinking that the key5 base64 is decoded at RR creation,
not by the eventual consumer?

> plain text or numeric octets but not both.

Exactly!   Which is why I am where I am.

> symbols where possible might turn out to work quite well.

I am not suggesting that you fish about in RFC3597 format.

If you are authoring from scratch than you can use this form:

        key65333=...
    END

If thou coverteth thy neighbour's RR in RFC3597 format (contrary to Exodus
20:17), there are the necessary tools to modify it:
        $value = $rr->keyNN();          # access a value (in your favoured
format)
        $rr->keyNN($value);             # assign a value
        $rr->keyNN(undef);              # delete a key

--Dick

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 22 Jul 2020 16:44:25 -0400

On Wed, Jul 22, 2020 at 4:28 PM Dick Franks <[email-masked]> wrote:

> It is not as easy as you might think.  This all needs to work on EBCDIC
> and UTF8 platforms.
>

The parsing is essentially the same as <character-string> for TXT records.
Whatever you have to do for those platforms should be the same, for better
or worse.

That's fine, of course.

> not by the eventual consumer?

Correct: echconfig's wire format is 8-bit binary, not base64, for maximum
efficiency.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Jul 2020 06:54:44 +1000

On a EBCDIC system you  need to run the record through ASCII / EBCDIC conversion for display purposes after converting from wire to ASCII. Those values that are not transformable use \DDD for, curly braces if I’m remembering  properly. Remember the presentation format is defined in terms of ASCII for its conversion to wire in DNS.

Presenting everything as \DDD is doing a disservice to your EBCDIC users.
-- 
Mark Andrews

> On 23 Jul 2020, at 03:27, Dick Franks <[email-masked]> wrote:
> 
> 
> 
> Except for the inconvenient fact that Net::DNS also works on OS390 which speaks EBCDIC. 
> 
> 
>> > Example:
>> > 
>> >     use Net::DNS;
>> > 
> I was only raising these exceptions on received packets, but the same tests are reasonable for freshly created RR.
> 
> --Dick

---

From: Dick Franks <[email-masked]>
Date: Tue, 28 Jul 2020 16:18:29 +0100

HTTPS and SVCB in Net::DNS 1.25_01 coming soon to a CPAN server near you.

Documentation needs more attention.

Thanks for the helpful comments, most of which are in there in some form or
another.

--Dick