> On Feb 20, 2022, at 4:21 PM, Martin Thomson <m...@lowentropy.net> wrote: > > I missed this text in draft-ietf-tls-tlsflags: > > A server that supports this extension and also supports at least one > of the flag-type features that use this extension and that were > declared by the ClientHello extension SHALL send this extension with > the intersection of the flags it supports with the flags declared by > the client. > > While sloppy on my part [1], I want to make it clear that this is a > show-stopper for me. Requiring an echo prevents a flag extension from > attaching semantics to a "response".
Based on discussion in the draft-kampanakis-tls-scas thread, there’s an open issue against the draft to track this clarification: https://github.com/tlswg/tls-flags/issues/19 Hopefully we’ll have a PR to clear this up soon. Relatedly, we’re going to pause this draft and draft-ietf-tls-cross-sni-resumption until we get some more implementation experience. Stay tuned for another message on that. > > I agree with Ilari's earlier point that these should work just like > extensions. If the server has no need to echo a flag, it should not be > required to do that. That allows the flag value in a "response" to carry > semantics. > > Cheers, > Martin > > [1] I missed this in the second WGLC, though in my defense, I don't think the > resolution and changes resulting from the first WGLC were very clearly > communicated. Indeed. I take the blame for not clearly communicating the end result of the first WGLC. That’s partly why we ran a second WGLC. Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
