Re: [TLS] tlsflags and "responses"

Hi. I have merged the PR following review and proposed changes by Chris and Martin Thomson. The only point that remains open is Ekr’a suggestion to allow (require?) sending the extension when empty. Yoav > On 22 Feb 2022, at 7:35, Yoav Nir wrote: > > I have just submitted PR #20 to allow

Re: [TLS] tlsflags and "responses"

I think it would probably be better to require it to be sent even if empty. Then you could measure how often it was implemented. On Mon, Feb 21, 2022 at 9:36 PM Yoav Nir wrote: > I have just submitted PR #20 to allow unacknowledged flags. It is a > rewrite of section 3 (rules) > >

Re: [TLS] tlsflags and "responses"

I have just submitted PR #20 to allow unacknowledged flags. It is a rewrite of section 3 (rules) https://github.com/tlswg/tls-flags/pull/20 It still requires that the flag extension not be sent when empty. Let me know if that’s a problem as well.

Re: [TLS] tlsflags and "responses"

Precisely. On Mon, Feb 21, 2022 at 2:42 PM Martin Thomson wrote: > On Tue, Feb 22, 2022, at 09:09, Benjamin Kaduk wrote: > > I think (but don't have a solid recollection) that this may have > > stemmed from a desire for the sender to know if the recipient supports > > flags at all. But

Re: [TLS] tlsflags and "responses"

On Tue, Feb 22, 2022, at 09:09, Benjamin Kaduk wrote: > I think (but don't have a solid recollection) that this may have > stemmed from a desire for the sender to know if the recipient supports > flags at all. But thinking about it now (and as Ekr's response > suggests), so long as we don't

Re: [TLS] tlsflags and "responses"

On Mon, Feb 21, 2022 at 11:21:38AM +1100, Martin Thomson 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

Re: [TLS] tlsflags and "responses"

> On Feb 20, 2022, at 4:21 PM, Martin Thomson 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

Re: [TLS] tlsflags and "responses"

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"