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.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
