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 <paul.hoff...@icann.org>
> 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.

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

Reply via email to