On Wed, Feb 23, 2022, at 09:31, Ben Schwartz wrote: > In TLS, I think "MUST" means "recipients should validate this if > possible and fail the handshake if there is a mismatch". Consider a > client implementation. Upon receipt of a SNIP response, is it supposed > to cross-check the SNIP answer vs. the ALPN offer, and fail if there is > intersection? This seems needlessly complicated.
So this "MUST/SHOULD omit compatible protocols" is really only there to do as David suggests: reduce variation. I don't think that we need it for correctness. I'm inclined to loosen this to a SHOULD. It's a little awkward in the sense that clients and servers might disagree about what protocols are compatible. That is - for QUIC at least - we allow for compatibility to be defined separately from the protocol, which means that some implementations might believe that a protocol is compatible when it is not. This leads to clients including things in ALPN that the server might also include in SNIP. https://github.com/tlswg/snip/pull/9 Ben's point about ALPN is well-taken though. This very much does assume that ALPN is in use. Indeed, it makes very little sense without it. So I'm going to suggest that we mandate it directly: https://github.com/tlswg/snip/pull/8 As for the appendix, I wonder if it is better left out entirely. I almost cut it last time, and this discussion makes me think that might be the easiest way out. There are some philosophical differences here that we should probably continue to discuss, but we don't need to resolve them if we agree about the conclusion (which is to do this validation in TLS and not rely on DNSSEC). https://github.com/tlswg/snip/pull/10 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
