On Thu, May 20, 2021 at 11:29 AM Ralf Weber <d...@fl1ger.de> 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:
- keyNNNN: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
- keyNNNN::mapping=value -- no label included
- keyNNNN=value -- no label included, default generic mapping
- keyNNNN: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 AAAA record - if multiple, space separated and double-quote
delimited; maps to a sequence of iPv6 addresses (AAAA record wire encoding)
- CSV - one or more strings, separated by commas, enclosed in double
quotes, as follows:
- inside quotes is encoded as the subset of printable-ASCII
characters in the range of decimal 32 to decimal 126 with escaped
(backslash) double-quote, escaped escape (double backslash), and also
permitting other 8-bit values as escaped-decimal values \DDD
- maps to sequence of (length | value) where each length is uint8 and
length(value) is between 1 and 255 inclusive.
- mapped value of one string from the list is the contents of the
substituted string (e.g. with escape substitutions performed) without the
enclosing quotes
- FQDN - a valid domain name; maps to wire-encoding for a domain name
- The defined field mappings may be added to by <TBD> process (RFC
required, Standards Action, other?)
Here's what I think the appropriate key/label/mapping should be for the
initial record and SvcParams:
- SVCB/HTTPS Resource Record is:
- SvcPriority (uint16)
- TargetName (FQDN)
- SvcParams (TLVSorted)
- SvcParams table keynum/label/mapping:
- 0/mandatory/uint16SortedList
- 1/alpn/CSV
- 2/no-default-alpn/flag
- 3/port/uint16
- 4/ipv4hint/ipv4list
- 5/ech/base64
- 6/ipv6hint/ipv6list
The specifics for alpn and CSV are somewhat novel, I realize, but I think
they are sufficiently unambiguous and well-defined to enable 2-way mappings
of arbitrary binary blobs of up to 255 characters, so can handle any
potential ALPN value.
Thus, the example used of foo\\,bar,h2 would be, as a CSV, "foo,bar","h2",
and in wire format would be "\x00 \x11 \x07 foo,bar \x02 h2".
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
