Subject: [TLS] Proposed change in TLS-Flags

From: Yoav Nir <[email-masked]>
Date: Tue, 30 Jun 2020 00:33:37 +0300

Hi

I’ve just submitted the following PR:

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

Three changes:
It is no longer allowed to send an empty flags extension.  If you don’t support any flags, don’t send the extension.
The server is no longer allowed to respond with flag types that the client didn’t indicate support for first.
I’ve split the extension description section into a format section and a rules section

Please comment. Barring any objections, I’ll merge the PR just before the submission deadline.

Yoav

---

From: David Schinazi <[email-masked]>
Date: Tue, 30 Jun 2020 16:30:38 -0700

Hi Yoav,

Could you elaborate on the rationale for this change please?
I was assuming that the ability for servers to send extensions not
requested by clients was useful.

Thanks,
David

On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir <[email-masked]> wrote:

> https://github.com/tlswg/tls-flags/pull/4
>
> Three changes:
>
>    - It is no longer allowed to send an empty flags extension.  If you
>    don’t support any flags, don’t send the extension.
>    - The server is no longer allowed to respond with flag types that the
>    client didn’t indicate support for first.
>    - I’ve split the extension description section into a format section
>    and a rules section
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nick Harper <[email-masked]>
Date: Tue, 30 Jun 2020 16:45:11 -0700

This was discussed in the WGLC thread (
https://mailarchive.ietf.org/arch/browse/tls/?gbt=1&index=973qdoi0PmJbJzNU7Y-eC_a-WaI).
I haven't seen any proposals of when it would be useful for a server to
send a flag unsolicited.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 1 Jul 2020 07:03:47 +0300

Yeah, the thread that Nick mentioned.

Also, since there are no such extensions defined in the base TLS 1.3 spec, the server can’t assume that the client knows what either the specific flag means, or the entire flags extension means. 

So suppose we invent some new client authentication scheme for TLS, it does make sense for the server to signal that it supports this so that the client can do. But I don’t think it’s too onerous to require that the client indicate support first.

Yoav

> On 1 Jul 2020, at 2:30, David Schinazi <[email-masked]> wrote:
> 
> Hi Yoav,
> 
> I was assuming that the ability for servers to send extensions not requested by clients was useful.
> 
> Thanks,
> David
> 
> On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> Hi
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 01 Jul 2020 14:17:21 +1000

More to the point, this makes it more difficult to analyze relative to an empty "flag" extension of the likes we currently use.

I haven't implemented this, but I imagine one strategy would be to rewrite these flags and pretend that they were empty extensions.  That would allow implementations to reuse a lot of infrastructure, like the stuff we added for custom extensions.  That would be more difficult if the server can speak first.

On Wed, Jul 1, 2020, at 14:03, Yoav Nir wrote:
> Also, since there are no such extensions defined in the base TLS 1.3 
> spec, the server can’t assume that the client knows what either the 
> specific flag means, or the entire flags extension means. 
> 
> So suppose we invent some new client authentication scheme for TLS, it 
> does make sense for the server to signal that it supports this so that 
> the client can do. But I don’t think it’s too onerous to require that 
> the client indicate support first.
> 
> Yoav
> 
> >>  * It is no longer allowed to send an empty flags extension. If you don’t support any flags, don’t send the extension.
> >>  * The server is no longer allowed to respond with flag types that the client didn’t indicate support for first.
> >>  * I’ve split the extension description section into a format section and a rules section
> >>