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 <brian.peter.dick...@gmail.com> wrote: > > > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
