On Tue, May 18, 2021 at 2:35 PM Paul Wouters <p...@nohats.ca> wrote: > On Tue, 18 May 2021, Ben Schwartz wrote: > > > That's essentially correct. A client that only supports the default > ALPN has no use for the "alpn" SvcParam. > > Does the "default ALPN" mean "no support for the ALPN extension" ? Or > does it mean "Supports ALPN with the default XXXX" ? If so, what is > XXXX? > > > My point is that SVCB mappings are IETF documents, complete with > guidance, normative language, deviations, exceptions, > > etc. The summary table in Appendix B is non-normative, and not > connected to IANA in any way. There is no registry of > > mappings. > > This really looks like you are creating an IANA registry for keywords > used within SVCB records. > > > Here is the same pair of records, using the two different encoding > schemes: > > ;; pool HTTPS 1 h3pool alpn=h2,h3 ech="123..." > > Why wouldn't this use: > > pool HTTPS 1 h3pool alpn="h2,h3" ech="123..." > > or: > > pool HTTPS 1 h3pool alpn="h2,h3", ech="123..." > > It is a little strange to me that some values are within quotes are > others are not. That really makes parsing (the presentation format) > harder. > > > It also creates significant complexity for any future value that takes > the form of an ordered list. > > Security protocols are usually in the form of the initiator represents a > list (in whatever order) and the responder decides which it picks and > prefers from that set and uses that. Putting ordered lists in seems like > something the client in this case would mostly ignore as they will just > pretend not to support that is ordered at a higher preference in a list > in the DNS record? > > But I did indicate already before that this RRtype is basically a > "security TXT" free flow record and it will surely lead to issues, yet > it seems unstoppable at this point anyway because of the milliseconds > for the advertisement auction gods. > > > I did a quick test implementation, and the wire overhead was not a > substantial increase, about 40%. > > > > This seems like a considerable increase for a high-traffic record type. > > Well, you basically build a security protocol demultiplexer server HELLO > record that's not protected by a Finished message, whose protection > comes from DNSSEC but the people who want to run this at scale don't > want to do DNSSEC. As long as the message size is well within common > EDNS UDP packet size (with RRSIGs), then I think the size does not > matter. > > I should have given the numbers as well as percentages. The original encoding for the response, including EDNS, was 191 bytes. The new encoding (continuing to use 16-bit values for SvcPriority, all the subtype values, and lengths, was 268 bytes. Trimming the SvcPriority and subtype sizes to 8 bits (for comparison purposes), but leaving lengths at 16 bits, the original encoding became 185 bytes Trimming SvcPriority, subtype, and length on the new encoding (because there won't be any single fields >250 bytes, assuming ALPN isn't insane), becomes 249 bytes.
So, the differences are either 77 bytes, or 66 bytes. For a host with a 1Gbps link (not uncommon), this is about 0.5 microseconds of extra serialization delay, or 1/2000th of a millisecond. Editing zone files and checking their accuracy/consistency is more trivial if the parsing is simpler and completely unambiguous. Most errors relate to syntax, not semantics. Providing a simple UI-like tool to either provide an input mechanism (to allow the user to fill in fields, and produce the DNS records) is pretty basic stuff, and reporting tools to output the associated elements (the reverse of the UI tool) is also extremely simple. Nothing on the wire will ever be a sorted list, modulo sorting of elements within a record. The client will always have to sort records itself. Sorting to do grouping is no different and no more complex than it is for handling the SvcPriority (which it must). And, in either encoding scheme, no matter how many records there are in the (unsorted) RRset, the DNSSEC RRSIG will be the same size: one record per ZSK. All the records combined are less than 256B, so there is no difference in efficiency for SHA256 (which requires padding). So, basically, all of the differences are for practical purposes below the noise floor. The benefits should be considered on the merits proposed, not any issues with the resulting wire format. IMNSHO. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
