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

[Brian Dickson <[e-mail]>]

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

>
>
> On Wed, May 19, 2021 at 7:01 PM Brian Dickson <
> [e-mail]> wrote:
>
>>
>>
>> On Wed, May 19, 2021 at 3:00 PM Brian Dickson <
>> [e-mail]> wrote:
>>
>>>
>>>
>>> On Wed, May 19, 2021 at 2:50 PM Paul Hoffman <[e-mail]>
>>> 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="f\\\\oo\\,bar,h2"
>> ( "" ; no-default-alpn is "no" aka not-present
>>   "" ; port - not present
>>   "" ; ech - not present
>>   "" ; ipv4hint - not present
>>   "" ; ipv6hint - not present
>>   "~foo,bar" "h2" ; list of alpn values, optional (marked with "~" on
>> first string meaning optional)
>> )
>>
>> ipv6hint="2001:db8::1,2001:db8::53:1"
>> ( "" ; no-default-alpn is "no" aka not-present
>>   "" ; port - not present
>>   "" ; ech - not present
>>   "" ; ipv4hint - not present
>>   "~2001:db8::1,2001:db8::53:1" ; ipv6hint, optional (per initial "~")
>>   "" ; alpn - not present
>> )
>>
>> port=53
>> ( "" ; no-default-alpn is "no" aka not-present
>>   "53" ; port
>>   "" ; ech - not present
>>   "" ; ipv4hint - not present
>>   "" ; ipv6hint - not present
>>   "" ; alpn - not present
>> )
>>
>> (No parameters other than priority and target)
>> ( "" ; no-default-alpn is "no" aka not-present
>>   "" ; port - not present
>>   "" ; ech - not present
>>   "" ; ipv4hint - not present
>>   "" ; ipv6hint - not present
>>   "" ; alpn - not present
>> )
>>
>> alpn=h2,h3 ech="123..."
>> ( "" ; no-default-alpn is "no" aka not-present
>>   "" ; port - not present
>>   "~123..." ; ech, not mandatory (marked with "~"
>>   "" ; ipv4hint - not present
>>   "" ; ipv6hint - not present
>>   "~h2" "h3" ; list of alpn values, optional (marked with "~")
>> )
>>
>> alpn=h2 ech="abc..."
>> ( "" ; no-default-alpn is "no" aka not-present
>>   "" ; port - not present
>>   "~abc..." ; ech, optional (not marked with "~")
>>   "" ; ipv4hint - not present
>>   "" ; ipv6hint - not present
>>   "~h2" ; (list of) alpn value(s), optional (marked with "~")
>> )
>>
>> ech="111..." ipv6hint=2001:db8::1 port=1234
>> ( "" ; no-default-alpn is "no" aka not-present
>>   "1234" ; port
>>   "111..." ; ech, optional (not marked with "~")
>>   "" ; ipv4hint - not present
>>   "~2001:db8::1" ; ipv6hint, optional (marked with "~")
>>   "" ; alpn - not present
>> )
>>
>> port=8002 ech="..."
>> ( "" ; no-default-alpn is "no" aka not-present
>>   "8002" ; port
>>   "~..." ; ech, optional (marked with "~")
>>   "" ; ipv4hint - not present
>>   "" ; ipv6hint - not present
>>   "" ; alpn - not present
>> )
>>
>> Compactness in a zone file format is not a feature, it is (IMNSHO) a bug.
>> Clarity and unambiguous parsing, and round-trip (zone->wire->zone) identity
>> are attributes that should be major considerations.
>>
>>
> Unless I'm missing something, this appears to remove the ability for
> extensibility by adding additional
> SvcParams in the future?  That is a major feature and "selling point" of
> HTTPS and SVCB records
> (and is even why "mandatory" exists) so I would not be in-favor of a
> proposal that removes the ability for future extensibility.
>

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

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

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

Brian