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

[DNSOP] SVCB/HTTPS, ECH, and AltSvc

[Martin Thomson]

Hey,

I've just opened https://github.com/MikeBishop/dns-alt-svc/issues/326

It's a bit long and I won't repeat it here, but I don't think that the current 
state of the document is good with respect to its handling of ECH and 
alternative services.

___
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] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

[Benjamin Kaduk]

Thanks, Job -- that looks better than anything I would have come up with!

-Ben

On Wed, May 19, 2021 at 01:10:27PM +0200, Job Snijders wrote:
> On Wed, May 19, 2021 at 12:28:16PM +0200, Peter van Dijk wrote:
> > > Section 3.1, etc.
> > > 
> > > |  The TTL of the NSEC RR that is returned MUST be the lesser of the
> > > |  MINIMUM field of the SOA record and the TTL of the SOA itself.
> > > |  This matches the definition of the TTL for negative responses in
> > > |  [RFC2308].  A signer MAY cause the TTL of the NSEC RR to have a
> > > |  deviating value after the SOA record has been updated, to allow
> > > |  for an incremental update of the NSEC chain.
> > > 
> > > I don't think I understand what a "deviating value" would be (and in
> > > which direction it would deviate).
> > 
> > This sentence was added because some implementations may need time to
> > rework the whole NSEC/NSEC3 chain after a TTL change. The deviation
> > would be 'part of the chain still has the old, wrong, value - for a
> > while'. I'll ponder better words - suggestions are very welcome, of
> > course.
> 
> Perhaps:
> 
>   Because some signers incrementally update the NSEC chain, a transient
>   inconsistency between the observed and expected TTL MAY exist.
> 
> Kind regards,
> 
> Job

___
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] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

[Job Snijders]

On Wed, May 19, 2021 at 12:28:16PM +0200, Peter van Dijk wrote:
> > Section 3.1, etc.
> > 
> > |  The TTL of the NSEC RR that is returned MUST be the lesser of the
> > |  MINIMUM field of the SOA record and the TTL of the SOA itself.
> > |  This matches the definition of the TTL for negative responses in
> > |  [RFC2308].  A signer MAY cause the TTL of the NSEC RR to have a
> > |  deviating value after the SOA record has been updated, to allow
> > |  for an incremental update of the NSEC chain.
> > 
> > I don't think I understand what a "deviating value" would be (and in
> > which direction it would deviate).
> 
> This sentence was added because some implementations may need time to
> rework the whole NSEC/NSEC3 chain after a TTL change. The deviation
> would be 'part of the chain still has the old, wrong, value - for a
> while'. I'll ponder better words - suggestions are very welcome, of
> course.

Perhaps:

Because some signers incrementally update the NSEC chain, a transient
inconsistency between the observed and expected TTL MAY exist.

Kind regards,

Job

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

Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

[Peter van Dijk]

Hello Benjamin,

On Tue, 2021-05-18 at 20:36 -0700, Benjamin Kaduk via Datatracker
wrote:
> --
> COMMENT:
> --
> 
> I put a (small) handful of editorial suggestions up at
> https://github.com/PowerDNS/draft-dnsop-nsec-ttl/pull/11 .

Thanks, I merged them!

> Section 3.1, etc.
> 
>|  The TTL of the NSEC RR that is returned MUST be the lesser of the
>|  MINIMUM field of the SOA record and the TTL of the SOA itself.
>|  This matches the definition of the TTL for negative responses in
>|  [RFC2308].  A signer MAY cause the TTL of the NSEC RR to have a
>|  deviating value after the SOA record has been updated, to allow
>|  for an incremental update of the NSEC chain.
> 
> I don't think I understand what a "deviating value" would be (and in
> which direction it would deviate).

This sentence was added because some implementations may need time to
rework the whole NSEC/NSEC3 chain after a TTL change. The deviation
would be 'part of the chain still has the old, wrong, value - for a
while'. I'll ponder better words - suggestions are very welcome, of
course.

> Section 3.4
> 
>|  A resolver that supports aggressive use of NSEC and NSEC3 MAY
>|  limit the TTL of NSEC and NSEC3 records to the lesser of the
>|  SOA.MINIMUM field and the TTL of the SOA in a response, if
>|  present.  It MAY also use a previously cached SOA for a zone to
>|  find these values.
> 
> The original 8198 has "SHOULD reduce", but now we only have "MAY limit".
> Why should the requirements level be weaker for the new, more-correct,
> guidance?

Rob Wilton also raised this - please see my reply here: 
https://mailarchive.ietf.org/arch/msg/dnsop/pMPe-KcbWUrFVcITCf3fmGk5ztY/

> Section 4
> 
>If signers & DNS servers for a zone cannot immediately be updated to
>conform to this document, zone operators are encouraged to consider
>setting their SOA record TTL and the SOA MINIMUM field to the same
>value.  That way, the TTL used for aggressive NSEC and NSEC3 use
>matches the SOA TTL for negative responses.
> 
> Are there any negative consequences of such a move that would need to be
> weighed against the stated benefits?

Signers might use either value (the SOA TTL or the SOA MINIMUM) as a
default for some other value. For example, PowerDNS uses the SOA
MINIMUM value as the TTL for DNSKEYs. So, lowering the SOA MINIMUM
would also lower the DNSKEY TTL (in PowerDNS).

A quick skim of the BIND dnssec-keygen manual page suggests that BIND
might sometimes take the SOA TTL as the DNSKEY TTL.

So, yes, there might be consequences. I will add a note.

> Section 8
> 
> Why is RFC 8174 only an informative reference?  Shouldn't it be given
> the same treatment as RFC 2119?

An oversight, already fixed in my local copy.

Thank you!
 
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] Robert Wilton's No Objection on draft-ietf-dnsop-nsec-ttl-04: (with COMMENT)

[Rob Wilton (rwilton)]

Hi Peter,


> -Original Message-
> From: Peter van Dijk 
> Sent: 18 May 2021 18:26
> To: Rob Wilton (rwilton) ; The IESG 
> Cc: draft-ietf-dnsop-nsec-...@ietf.org; dnsop-cha...@ietf.org;
> dnsop@ietf.org; tjw.i...@gmail.com
> Subject: Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-
> nsec-ttl-04: (with COMMENT)
> 
> Hello Rob,
> 
> On Tue, 2021-05-18 at 08:04 -0700, Robert Wilton via Datatracker wrote:
> > --
> > COMMENT:
> > --
> >
> > Hi,
> >
> > Thanks for this document.
> >
> > Regarding:
> >
> > 3.4.  Updates to RFC8198
> >
> >[RFC8198] section 5.4 (Consideration on TTL) is completely replaced
> >by the following text:
> >
> >|  The TTL value of negative information is especially important,
> >|  because newly added domain names cannot be used while the negative
> >|  information is effective.
> >|
> >|  Section 5 of [RFC2308] suggests a maximum default negative cache
> >|  TTL value of 3 hours (10800).  It is RECOMMENDED that validating
> >|  resolvers limit the maximum effective TTL value of negative
> >|  responses (NSEC/NSEC3 RRs) to this same value.
> >|
> >|  A resolver that supports aggressive use of NSEC and NSEC3 MAY
> >|  limit the TTL of NSEC and NSEC3 records to the lesser of the
> >|  SOA.MINIMUM field and the TTL of the SOA in a response, if
> >|  present.  It MAY also use a previously cached SOA for a zone to
> >|  find these values.
> >
> > I'm not a DNS expert, and this is just a non binding comment, but I was
> > wondering why it is only "MAY" limit the TTL on NSEC and NSEC3 records
> to the
> > lesser of the SOA.MINIMUM field and the TTL of the SOA in a response
> rather
> > than a "SHOULD".
> 
> Thank you for your comment.
> 
> The old text was this:
> 
> > A resolver that supports aggressive use of NSEC and NSEC3 SHOULD reduce
> the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM field in the
> authority section of a negative response, if SOA.MINIMUM is smaller.
> 
> but this text did nothing (this is also noted in section 1 of the draft),
> as signers/authoritatives already took that TTL from the SOA.MINIMUM field
> - which this document corrects.
> 
> Furthermore, during WG discussion we realised that in many cases, a
> validator handling NSEC/NSEC3 records would not have access to the
> relevant SOA at all - for example, in wildcard responses. 'SHOULD' is
> quite strong language for something that often is not even possible.
[RW] 
I agree.

> 
> And, finally, the MAY you ask about is behaviour that is only useful in
> validators until signers/authoritatives become compliant with this draft.
> It is a secondary measure (that the WG explicitly requested so as to
> attempt to solve the problem in multiple places) that should become
> irrelevant as signers (most of which already have software fixes pending,
> merged, or released) get upgraded.
> 
> I hope this answers your question; please let me know if not.
[RW] 
I think so, or at least I'm happy to defer to the WG's judgement here.

Thanks for the explanation.

Regards,
Rob


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