Subject: [TLS] tlsflags and "responses"

From: "Martin Thomson" <[email-masked]>
Date: Mon, 21 Feb 2022 11:21:38 +1100

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.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Feb 2022 16:57:10 -0800

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 <[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Christopher Wood <[email-masked]>
Date: Sun, 20 Feb 2022 17:41:42 -0800

> On Feb 20, 2022, at 4:21 PM, Martin Thomson <[email-masked]> wrote:
> 

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.

> [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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 21 Feb 2022 14:09:04 -0800

> 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 "re…

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 allocate flags for existing extensions, there is not much useful to do with that information in cases where the extension semantics of the flag(s) in question don't require a response.

-Ben

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 22 Feb 2022 09:41:48 +1100

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 allocate flags for existing extensions, 
> there is not much useful to do with that information in cases where the 
> extension semantics of the flag(s) in question don't require a response.

Wouldn't it be possible to send the extension with an empty set of flags?  We don't permit trailing zero bytes, but a zero-length sequence indicates support without signaling for any specific flag.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Feb 2022 15:07:24 -0800

Precisely.

On Mon, Feb 21, 2022 at 2:42 PM Martin Thomson <[email-masked]> wrote:

> Wouldn't it be possible to send the extension with an empty set of flags?
> We don't permit trailing zero bytes, but a zero-length sequence indicates
> support without signaling for any specific flag.
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Feb 2022 07:35:36 +0200

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 <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.

Yoav

> On 21 Feb 2022, at 2:21, Martin Thomson <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 Feb 2022 11:50:22 -0800

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 <[email-masked]> wrote:

> https://github.com/tlswg/tls-flags/pull/20
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Feb 2022 22:43:04 +0200

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 <[email-masked]> wrote:
> 
>> On 21 Feb 2022, at 2:21, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>