On Tue, May 07, 2024 at 08:05:05AM -0700, David Benjamin wrote: > > draft-ietf-tls-wkech seems like a good model for this, but it is currently > written specifically for ECH. What are your thoughts on generalizing that > document to cover other cases as well? > https://github.com/sftcd/wkesni/issues/14 > > We might also think about the extension model for that document. Does each > SvcParamKey opt into use with the document, with its own JSON key and text > describing how to map it, or should we just use the presentation syntax and > import it all en masse? (I'm not sure. The latter would certainly be less > work for new SvcParamKeys, but I'm not sure what the implications would be > of the DNS frontend picking up SvcParamKeys it doesn't understand. Then > again, we seem to have happily imported basically all the existing keys > anyway.)
It seems to me that SvcParamKey's can be divided into three groups: 1) Properties of the server that don't affect protocol. E.g., ech, tls-supported-groups, no-default-alpn These should be picked by the DNS frontend. 2) Properites related to location of the server. E.g., port, ipv4hint, ipv6hint These should not be picked by the DNS frontend, but instead should be set by the DNS frontend configuration (or at least specify how to set these). 3) Gateway-special properties E.g., alpn These would initially seem to be server properties. However, these can affect the protocol used (e.g., h2 and h3 are very different), so in some situations, DNS frontend needs to handle it specially. One such situation is if the server is gatewayed. In such situation, the DNS frontend needs to drop all the alpn values not supported in the gateway (especially h3 needs to be dropped). Servers can also be gatewayed in IPv4 but direct in IPv6. In that situation, the DNS fronted needs to duplicate the records, with IPv4 side having filtered alpn values and IPv6 side having all the alpn values. There seems to be no guarantees about which category future SvcParamKeys fall into. While the second group just should not be specified at all, a new parameter in the third group could cause problems, as not filtering those correctly can cause breakage. -Ilari _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
