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

[Dick Franks]

On Mon, 24 May 2021 at 15:52, Ben Schwartz  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
> [2] https://github.com/MikeBishop/dns-alt-svc/pull/325/files
>
> On Sat, May 22, 2021 at 12:58 PM Dick Franks  wrote:
>>
>> On Sat, 22 May 2021 at 17:06, Paul Hoffman  wrote:
>> >
>> > On May 22, 2021, at 1:58 AM, Dick Franks  wrote:
>> >
>> > > Please find attached the promised words to resolve the conflict
>> > > between current draft and RFC1035.
>> > >
>> > > This is presented as a context diff.
>> >
>> > Where do we find the original Markdown file so we can evaluate the diff?
>>
>> https://github.com/MikeBishop/dns-alt-svc
>>
>> --Dick
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ben Schwartz]

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

On Sat, May 22, 2021 at 12:58 PM Dick Franks  wrote:

> On Sat, 22 May 2021 at 17:06, Paul Hoffman  wrote:
> >
> > On May 22, 2021, at 1:58 AM, Dick Franks  wrote:
> >
> > > Please find attached the promised words to resolve the conflict
> > > between current draft and RFC1035.
> > >
> > > This is presented as a context diff.
> >
> > Where do we find the original Markdown file so we can evaluate the diff?
>
> https://github.com/MikeBishop/dns-alt-svc
>
> --Dick
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ralf Weber]

Moin!

On 21 May 2021, at 20:16, Brian Dickson wrote:
> I think the handling of presentation formats and wire formats leaves much
> to be desired.
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.

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

> So, this problem on sub-field encodings has arisen from ignoring RFC5507
> (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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On Sat, 22 May 2021 at 17:06, Paul Hoffman  wrote:
>
> On May 22, 2021, at 1:58 AM, Dick Franks  wrote:
>
> > Please find attached the promised words to resolve the conflict
> > between current draft and RFC1035.
> >
> > This is presented as a context diff.
>
> Where do we find the original Markdown file so we can evaluate the diff?

https://github.com/MikeBishop/dns-alt-svc

--Dick

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On May 22, 2021, at 1:58 AM, Dick Franks  wrote:

> Please find attached the promised words to resolve the conflict
> between current draft and RFC1035.
> 
> This is presented as a context diff.

Where do we find the original Markdown file so we can evaluate the diff?

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

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



draft-ietf-dnsop-svcb-https.diff.gz
Description: application/gzip
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

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

>
>
> On Thu, May 20, 2021 at 11:29 AM Ralf Weber  wrote:
>
>> Moin!
>>
>> On 20 May 2021, at 19:59, Eric Orth wrote:
>>
>> > 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.
>> 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.
>>
>
> 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:
>
>- key: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
>- key::mapping=value -- no label included
>- key=value -- no label included, default generic mapping
>- key: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  record - if multiple, space separated and double-quote
>delimited; maps to a sequence of iPv6 addresses ( record wire encoding)

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

[Ralf Weber]

Moin!

On 20 May 2021, at 19:59, Eric Orth wrote:

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ralf Weber]

Moin!

On 20 May 2021, at 3:32, Brian Dickson wrote:
> (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.
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 20 May 2021, at 12:31, Brian Dickson  wrote:
> 
> 
> 
> On Wed, May 19, 2021 at 7:15 PM Mark Andrews  wrote:
> 
> 
> > On 20 May 2021, at 11:52, Paul Wouters  wrote:
> > 
> > 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.
> 
> Or detect them and switch to key1=“…” instead of alpn=“…” when displaying
> entry would need to be using key 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"
> 
> I don't understand why any of the comma-escaping is needed at all, honestly.
> 
> RFC1035 has the definition of  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.

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=[,]* 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.

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
>  

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 19, 2021 at 7:15 PM Mark Andrews  wrote:

>
>
> > On 20 May 2021, at 11:52, Paul Wouters  wrote:
> >
> > 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.
>
> Or detect them and switch to key1=“…” instead of alpn=“…” when displaying
> entry would need to be using key 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"
>

I don't understand why any of the comma-escaping is needed at all, honestly.

RFC1035 has the definition of  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=[,]* 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 20 May 2021, at 11:52, Paul Wouters  wrote:
> 
> 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.

Or detect them and switch to key1=“…” instead of alpn=“…” when displaying
entry would need to be using key 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"

> Paul
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

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

> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly  40apple@dmarc.ietf.org> 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.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Martin Thomson]

On Thu, May 20, 2021, at 11:32, Brian Dickson wrote:
> Is it one of those things that are "Well, we think we might need 
> 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 19, 2021 at 5:52 PM Martin Thomson  wrote:

> 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'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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 19, 2021 at 6:15 PM Martin Thomson  wrote:

> On Thu, May 20, 2021, at 11:08, Paul Wouters wrote:
> > 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.
>
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Martin Thomson]

On Thu, May 20, 2021, at 11:08, Paul Wouters wrote:
> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Thu, 20 May 2021, Martin Thomson wrote:


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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Martin Thomson]

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 19, 2021 at 5:15 PM Erik Nygren  wrote:

>
>
> On Wed, May 19, 2021 at 7:01 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 19, 2021 at 3:00 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman 
>>> 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.
>>>
>>
>> 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="foo\\,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
>>   "" 

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

[Erik Nygren]

On Wed, May 19, 2021 at 7:01 PM Brian Dickson 
wrote:

>
>
> On Wed, May 19, 2021 at 3:00 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman 
>> 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.
>>
>
> 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="foo\\,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 

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

[Brian Dickson]

On Wed, May 19, 2021 at 3:00 PM Brian Dickson 
wrote:

>
>
> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman 
> 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.
>

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="foo\\,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 "~"
  "" ; 

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

[Eric Orth]

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.



On Wed, May 19, 2021 at 6:01 PM Brian Dickson 
wrote:

>
>
> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman 
> 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
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 19, 2021 at 2:50 PM Paul Hoffman  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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tommy Pauly]

> On May 19, 2021, at 2:37 PM, Erik Nygren  wrote:
> 
> 
> 
> 
>> On Wed, May 19, 2021 at 5:12 PM Tommy Pauly  wrote:
>> 
>> 
>>> On May 19, 2021, at 1:34 PM, Brian Dickson  
>>> wrote:
>>> 
>>> 
>>> 
>>> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly  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?
>> 
>> 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?

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). 
> 
> 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
> 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

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

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Erik Nygren]

On Wed, May 19, 2021 at 5:12 PM Tommy Pauly  wrote:

>
>
> On May 19, 2021, at 1:34 PM, Brian Dickson 
> wrote:
>
>
>
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly  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?
>
>
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

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

>
>
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly  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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tommy Pauly]

> On May 19, 2021, at 1:34 PM, Brian Dickson  
> wrote:
> 
> 
> 
> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly  > 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?

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 19, 2021 at 7:49 AM Tommy Pauly  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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tommy Pauly]

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  wrote:
> 
> 
> On Mon, May 17, 2021 at 5:36 PM Ben Schwartz 
> mailto:40google@dmarc.ietf.org>> 
> wrote:
> 
> 
> On Sat, May 15, 2021 at 12:48 PM Brian Dickson  > wrote:
> 
> 
> On Thu, May 13, 2021 at 10:25 AM Ben Schwartz  > wrote:
> 
> 
> On Thu, May 13, 2021 at 12:51 AM Brian Dickson  > wrote:
> 
> 
> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz  > 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
> 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..." 
> 
> 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 
> 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
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org

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

[Brian Dickson]

On Tue, May 18, 2021 at 2:35 PM Paul Wouters  wrote:

> 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 " ? If so, what is
> ?
>
> > 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.
>
> > Here is the same pair of records, using the two different encoding
> schemes:
> > ;; 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%.
> >
> > This seems like a considerable increase for a high-traffic record type.
>
> 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.
>
>
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

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 " ? If so, what is
?


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.


Here is the same pair of records, using the two different encoding schemes:
;; 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%. 

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


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Mon, May 17, 2021 at 3:48 PM Ben Schwartz  wrote:

> On Mon, May 17, 2021 at 2:46 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> 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.
>>
>
> 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.
>
> ...
>
>> 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
>>
>> 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.)
>

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.


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

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?


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

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.


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

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 

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

[Ben Schwartz]

On Mon, May 17, 2021 at 2:46 PM Brian Dickson 
wrote:

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

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.

...

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

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

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

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

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

[Erik Nygren]

On Mon, May 17, 2021 at 5:36 PM Ben Schwartz  wrote:

>
>
> On Sat, May 15, 2021 at 12:48 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Thu, May 13, 2021 at 10:25 AM Ben Schwartz  wrote:
>>
>>>
>>>
>>> On Thu, May 13, 2021 at 12:51 AM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>>


 On Wed, May 12, 2021 at 9:33 PM Ben Schwartz  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
>> 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..."
>>
>
> 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
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

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 <
brian.peter.dick...@gmail.com> wrote:

>
>
> On Thu, May 13, 2021 at 10:25 AM Ben Schwartz  wrote:
>
>>
>>
>> On Thu, May 13, 2021 at 12:51 AM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz  wrote:
>>>
 On Wed, May 12, 2021 at 7:14 PM Brian Dickson <
 brian.peter.dick...@gmail.com> 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.
>>
>> Switching to a zone file format that is simpler to parse would go a long
>>> way to improving those.
>>>
>>
>>
>> Considering alternative formats is an intriguing exercise, but I do not
>> 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:
>
>> 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 

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

[Brian Dickson]

On Sat, May 15, 2021 at 8:00 AM Erik Nygren  wrote:

> On Wed, May 12, 2021 at 4:44 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> 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.
>>
>
> 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.
>

Currently, the singular AliasMode (chain, but non-forking chain) still
requires potentially multiple ServiceMode records to be handled, including
queries for A and  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).


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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Thu, May 13, 2021 at 10:25 AM Ben Schwartz  wrote:

>
>
> On Thu, May 13, 2021 at 12:51 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Wed, May 12, 2021 at 9:33 PM Ben Schwartz  wrote:
>>
>>> On Wed, May 12, 2021 at 7:14 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> 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.
>
> Switching to a zone file format that is simpler to parse would go a long
>> way to improving those.
>>
>
>
> Considering alternative formats is an intriguing exercise, but I do not
> 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:

> 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 A192.0.2.2
>    2001:db8::2
> h3pool 300 IN A192.0.2.3
>    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..."


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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Erik Nygren]

On Wed, May 12, 2021 at 4:44 PM Brian Dickson 
wrote:

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Fri, May 14, 2021 at 5:47 PM John Levine  wrote:

> It appears that Brian Dickson   said:
> >I said you weren't going to like it.
>
> No disagreement there.
>
> >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".
>
> 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.
>

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

It appears that Brian Dickson   said:
>I said you weren't going to like it.

No disagreement there.

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Thu, May 13, 2021 at 10:50 AM Ben Schwartz  wrote:

>
>
> On Thu, May 13, 2021 at 3:56 AM libor.peltan  wrote:
>
>> Hi all,
>>
>> just my comment:
>>
>> 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
>>
>> 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,
>>
> 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).
>
>> 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

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

[John R Levine]

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.


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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

On Thu, 13 May 2021, Ben Schwartz wrote:

SVCB's key=value zone-file format is borrowed straight from DNS-SD (RFC
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

 - verify their uniqueness
 - deal with list of fields nested in other fields (this includes the
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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ben Schwartz]

On Thu, May 13, 2021 at 3:56 AM libor.peltan  wrote:

> Hi all,
>
> just my comment:
>
> 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
>
> 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,
>
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.

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[libor.peltan]

Hi all,

just my comment:

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 12, 2021 at 9:33 PM Ben Schwartz  wrote:

> On Wed, May 12, 2021 at 7:14 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> 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, , plus DNSSEC and TLSA support in the clients, which are email
>> transport things, not merely DNS things.)
>>
>
> 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
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.


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

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
> implementations [3] will serve as convincing evidence that the current
> draft is sufficient in that regard.
>

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

(The history of SMTP is, I think, a good poster child for this, with MX,
A, , plus DNSSEC and TLSA support in the clients, which are email
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.



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


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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 12, 2021 at 3:32 PM Eric Orth  wrote:

>
>
> On Wed, May 12, 2021 at 6:21 PM John Levine  wrote:
>
>> It appears that Joe Abley   said:
>> >> 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.
>

 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,
, plus DNSSEC and TLSA support in the clients, which are email
transport things, not merely DNS things.)

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 13 May 2021, at 07:46, Joe Abley  wrote:
> 
> On 12 May 2021, at 17:39, John Levine  wrote:
> 
>> It appears that Joe Abley   said:
>> 
>>> 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.
> 
> 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.

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.

> Joe
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 12 May 2021, at 17:39, John Levine  wrote:

> It appears that Joe Abley   said:
> 
>> 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.

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

It appears that Joe Abley   said:
>> 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?

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Eric Orth]

On Wed, May 12, 2021 at 4:44 PM Brian Dickson 
wrote:

>
>
> On Wed, May 12, 2021 at 12:28 PM Eric Orth  40google@dmarc.ietf.org> 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.
>>
>
> 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.
>

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.


>
> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 12 May 2021, at 17:03, Eric Orth  
wrote:

> On Wed, May 12, 2021 at 4:28 PM Brian Dickson  
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Eric Orth]

On Wed, May 12, 2021 at 4:28 PM Brian Dickson 
wrote:

>
>
> On Wed, May 12, 2021 at 12:28 PM Eric Orth  40google@dmarc.ietf.org> wrote:
>
>> 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.
>>
>
> 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".
>

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


>
> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 12, 2021 at 12:28 PM Eric Orth  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.
>

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Wed, May 12, 2021 at 12:28 PM Eric Orth  wrote:

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Eric Orth]

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

> 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,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter van Dijk]

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,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Tue, May 11, 2021 at 4:16 PM Ben Schwartz  wrote:

>
>
> On Tue, May 11, 2021 at 4:13 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> ...
>
>> 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.)
>>
>
> 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  records of foo.example.net will be used.
>

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Tue, May 11, 2021 at 4:00 PM Ben Schwartz  wrote:

>
>
> On Tue, May 11, 2021 at 3:44 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Tue, May 11, 2021 at 2:49 PM Ben Schwartz  wrote:
>>
>>>
>>>
>>> On Tue, May 11, 2021 at 2:31 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> wrote:
>>> ...
>>>
 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?

>>>
>>> It sounds like one of the deployment arrangements that is anticipated by
>>> the draft.
>>> ...
>>>
 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.

>>>
>>> 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
>>> ).
>>>
>>>
>>
>> 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)?
>>
>
> 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.
>

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Tue, May 11, 2021 at 2:49 PM Ben Schwartz  wrote:

>
>
> On Tue, May 11, 2021 at 2:31 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> ...
>
>> 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?
>>
>
> It sounds like one of the deployment arrangements that is anticipated by
> the draft.
> ...
>
>> 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.
>>
>
> 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
> ).
>
>

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 

foo.example.com.cdn2.example.net HTTPS 1 . alpn=h2,h3
foo.example.com.cdn2.example.net A 
foo.example.com.cdn2.example.net  

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


> ...
>
>> 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).
>>
>
> Yes, this is the goal of the draft, and the behavior documented by the
> draft's CDN examples.
>
>

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Brian Dickson]

On Tue, May 11, 2021 at 11:12 AM Ben Schwartz  wrote:

>
>
> On Tue, May 11, 2021 at 10:32 AM Joe Abley  wrote:
>
>> On 11 May 2021, at 12:32, Ben Schwartz  wrote:
>>
>> > On Tue, May 11, 2021 at 9:20 AM Joe Abley  wrote:
>> >> On 11 May 2021, at 12:08, Ben Schwartz > 40google@dmarc.ietf.org> wrote:
>> >> ..
>> >>> * It saves at least 11 bytes of overhead per parameter by avoiding
>> repetition of
>> >>>   the name, type, class, TTL, and inter-pair binding ID.
>> >
>> > ... 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.
>>
>> 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.
>>
>
>>
> This design choice, like many aspects of SVCB, was constrained by latency
> and efficiency considerations.
>

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


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

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


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

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 

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

[Ben Schwartz]

On Tue, May 11, 2021 at 10:32 AM Joe Abley  wrote:

> On 11 May 2021, at 12:32, Ben Schwartz  wrote:
>
> > On Tue, May 11, 2021 at 9:20 AM Joe Abley  wrote:
> >> On 11 May 2021, at 12:08, Ben Schwartz  40google@dmarc.ietf.org> wrote:
> >> ..
> >>> * It saves at least 11 bytes of overhead per parameter by avoiding
> repetition of
> >>>   the name, type, class, TTL, and inter-pair binding ID.
> >
> > ... 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.
>
> 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.

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

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

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 11 May 2021, at 12:32, Ben Schwartz  wrote:

> On Tue, May 11, 2021 at 9:20 AM Joe Abley  wrote:
>> On 11 May 2021, at 12:08, Ben Schwartz  
>> wrote:
>> ..
>>> * It saves at least 11 bytes of overhead per parameter by avoiding 
>>> repetition of
>>>   the name, type, class, TTL, and inter-pair binding ID.
> 
> ... 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.

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?

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

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


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ben Schwartz]

On Tue, May 11, 2021 at 9:41 AM Dick Franks  wrote:

> 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..
>
> On Sun, 9 May 2021 at 13:01, Dick Franks  wrote:
> >8
> >
> > 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
> >
>
> 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.INSVCB( \# 38 0001 ; 1
> 03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
> 0006 000f 20010db85c2c00 )
>
> instead of the expected:
>
>  example.com.INSVCB( \# 39 0001 ; 1
> 03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
> 0006 0010 20010db85c5c2c00 )
>
> 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


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

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

On Sun, 9 May 2021 at 13:01, Dick Franks  wrote:
>8
>
> 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
>

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.INSVCB( \# 38 0001 ; 1
03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
0006 000f 20010db85c2c00 )

instead of the expected:

 example.com.INSVCB( \# 39 0001 ; 1
03666f6f076578616d706c6503636f6d 00 ; foo.example.com.
0006 0010 20010db85c5c2c00 )

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ben Schwartz]

On Tue, May 11, 2021 at 9:20 AM Joe Abley  wrote:

> Hi Ben,
>
> On 11 May 2021, at 12:08, Ben Schwartz 
> wrote:
>
..

> * It saves at least 11 bytes of overhead per parameter by avoiding
> repetition of
>   the name, type, class, TTL, and inter-pair binding ID.
>
>
> ... 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.

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


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[libor.peltan]

Hi Ben,

Dne 11. 05. 21 v 18:08 Ben Schwartz napsal(a):



On Tue, May 11, 2021 at 3:31 AM libor.peltan > 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:

Thank you for at least this effort.


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


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


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

Libor
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hi Ben,

On 11 May 2021, at 12:08, Ben Schwartz  
wrote:

> OK, I've proposed text documenting the reasoning here: 
> 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
> 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.

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.

> * It makes each record independently meaningful, consistent with the usual
>   convention for DNS records (c.f. SRV, MX, , 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 , 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
>   the name, type, class, TTL, and inter-pair binding ID.

... 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
>   of each key=value pair, and avoids requiring cross-RR reconstruction of
>   bindings by the client.

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


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Vladimír Čunát]

On 11. 05. 21 1:59, Brian Dickson wrote:
IMNSHO, it'll be faster to discard any existing parsing code, and 
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.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[libor.peltan]

Hi all,

this is actually not the first time someone has come with this issue: 
https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1=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 
> 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]

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
                   2001:db8::2
h3pool 300 IN A        192.0.2.3
                   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..." } }, ...]

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

[Brian Dickson]

On Mon, May 10, 2021 at 9:58 AM Ben Schwartz  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]

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 A192.0.2.2
   2001:db8::2
h3pool 300 IN A192.0.2.3
   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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On May 10, 2021, at 4:14 PM, Mark Andrews  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

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 11 May 2021, at 08:46, Paul Hoffman  wrote:
> 
> On May 10, 2021, at 9:56 AM, Ben Schwartz 
>  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.

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


>> As for the question of commas, I continue to 

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

[Stephen Farrell]

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
specification that is now widely deployed.


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.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On May 10, 2021, at 9:56 AM, Ben Schwartz  
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 -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.

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

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Mark Andrews]

> On 11 May 2021, at 02:56, Ben Schwartz  
> 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):
> 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 thi
 s 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
> [2] https://github.com/MikeBishop/dns-alt-svc/pull/282
> 
> 
> On Mon, May 10, 2021 at 8:35 AM Joe Abley  wrote:
> Hi Pieter,
> 
> On 10 May 2021, at 11:23, Pieter Lexis  wrote:
> 
>> You then invite the following issues:
>> 
>> Clients need to match the tuple (ownername + prio + target) and get all
>> data from all matched rrsets, whereas now you get all that data in one
>> piece of rdata.
> 
> Inviting that issue is also a potential benefit, but I agree that the 
> implication exists. For example, the ability to publish sets of SvcParams 
> with long TTLs ought to increase the probability of cache hits for that data 
> and reduce SVCB response sizes.
> 
>> A client also can't figure out (if not doing DNSSEC valdiation
>> themselves) if you have received all the SVC data for a certain name.
> 
> A client can't figure out without DNSSEC whether anything they have received 
> is correct in, in general. So setting 

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

[Paul Wouters]

On Mon, 10 May 2021, Ben Schwartz wrote:


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On Mon, 10 May 2021, Joe Abley wrote:


   $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


A zone owner/editor would never even think of typing in IP addresses
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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Peter van Dijk]

On Mon, 2021-05-10 at 16:43 +0200, Pieter Lexis wrote:
> Hi Dick,
> 
> On 5/10/21 1:02 PM, Dick Franks wrote:
> > 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.
> 
> If you have the words to fix this issue that would need to changes the
> 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/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hi Ben,

On 10 May 2021, at 12:56, Ben Schwartz  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


signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hi Pieter,

On 10 May 2021, at 11:23, Pieter Lexis  wrote:

> You then invite the following issues:
> 
> Clients need to match the tuple (ownername + prio + target) and get all
> data from all matched rrsets, whereas now you get all that data in one
> piece of rdata.

Inviting that issue is also a potential benefit, but I agree that the 
implication exists. For example, the ability to publish sets of SvcParams with 
long TTLs ought to increase the probability of cache hits for that data and 
reduce SVCB response sizes.

> A client also can't figure out (if not doing DNSSEC valdiation
> themselves) if you have received all the SVC data for a certain name.

A client can't figure out without DNSSEC whether anything they have received is 
correct in, in general. So setting aside that more general authentication 
problem, I don't think it's correct to say that a client cannot tell whether 
they have received a complete RRSet in the answer section of a response. It's 
either there and complete or it's absent (and perhaps TC=1 if the reason for 
its absence is message truncation).

There should be no response possible in an implementation that adheres to the 
protocol in which a truncated RRSet appears in the answer section. If we're 
widening the net to implementations that don't follow the rules then I agree 
anything is possible.


Joe___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Pieter Lexis]

Hi Joe,

On 5/10/21 1:42 AM, Joe Abley wrote:
> On May 9, 2021, at 19:27, Paul Hoffman  wrote:
> 
>> 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. 
> 
> 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 proble>
> 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).

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Pieter Lexis]

Hi Dick,

On 5/10/21 1:02 PM, Dick Franks wrote:
> 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.

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

Cheers,

Pieter

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On Mon, 10 May 2021 at 00:28, Paul Hoffman  wrote:
>
> On May 9, 2021, at 11:26 AM, Paul Wouters  wrote:
> > 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.
>
> 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
>

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.


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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On May 10, 2021, at 05:42, Pieter Lexis  wrote:

>> On 5/9/21 2:01 PM, Dick Franks wrote:
>> 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
> 
> A zone owner/editor would never even think of typing in IP addresses
> 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Pieter Lexis]

Hi Dick,

On 5/9/21 2:01 PM, Dick Franks wrote:
> 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

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On Mon, 10 May 2021 at 00:42, Joe Abley  wrote:
>
> On May 9, 2021, at 19:27, Paul Hoffman  wrote:
>
> > 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.
>
> 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.

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

>8

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

Perhaps this horse needs to be tested for banned substances!


--Dick

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On May 9, 2021, at 19:27, Paul Hoffman  wrote:

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

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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On May 9, 2021, at 11:26 AM, Paul Wouters  wrote:
> 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.

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

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Wouters]

On May 9, 2021, at 08:02, Dick Franks  wrote:
> 
> 
>$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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On Fri, 7 May 2021 at 16:52, Paul Hoffman  wrote:
>
> On May 7, 2021, at 3:21 AM, Pieter Lexis  wrote:
> > 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.

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

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On May 7, 2021, at 3:21 AM, Pieter Lexis  wrote:
> 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.

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

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tim Wicinski]

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


On Fri, May 7, 2021 at 9:19 AM Dick Franks  wrote:

> On Fri, 7 May 2021 at 11:21, Pieter Lexis 
> wrote:
> >
> >8
> >
> > 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.
>
> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dick Franks]

On Fri, 7 May 2021 at 11:21, Pieter Lexis  wrote:
>
>8
>
> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Pieter Lexis]

Hi folks,

On 5/6/21 10:16 PM, Dick Franks wrote:
> On Thu, 6 May 2021 at 19:11, Ben Schwartz  wrote:
>> On Thu, May 6, 2021 at 8:50 AM Dick Franks  wrote:
>>> 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.
>>
>> 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.
, respectively).
> [...]
> That is no justification at all.   SPF people can do whatever they
> like within the arguments of a TXT record.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tom]

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:


On Thu, 6 May 2021 at 19:11, Ben Schwartz  wrote:
On Thu, May 6, 2021 at 8:50 AM Dick Franks  wrote: 
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,...".

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!


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.


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop