I agree with MT. The right way to think of this extension is as a compression mechanism that matches the semantics of otherwise empty extensions. And in that case, we should retain the semantics of not echoing the extension, which is to say "I didn't accept it, whether I know about it or not"
-Ekr On Sun, Feb 20, 2022 at 4:22 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". > > 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. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
