Subject: [TLS] TLS Flags Open Question

From: Yoav Nir <[email-masked]>
Date: Sat, 5 Dec 2020 17:04:58 +0200

Hi.

At IETF 108 a question was raised about The TLS Flags extension.  What  payloads on the server side can include this extension?

The “candidates” are ServerHello, EncryptedExtensions, Certificate, and NewSessionTicket.

The only one that is controversial here (I think) is ServerHello, because it is not encrypted.  Looking at the current list of extensions, I see that only 6 can go in ServerHello:
password_salt
tls_cert_with_extern_psk
supported_ekt_ciphers
pre_shared_key
supported_versions
key_share

Of those, only one would be (if it hadn’t already been standardized) a candidate for the TLS-Flags extension: tls_cert_with_extern_psk.  The RFC describes it with “The “tls_cert_with_extern_psk" extension is essentially a flag to use the external PSK in the key schedule”.  I don’t think it’s unreasonable to think that at some point there’s going to be another flag-like extension that will need to be signalled in ServerHello.

So the question for the group is, do we allow the flags extension (and the flags themselves) to be in ServerHello, or do we prohibit them for now, and if ever an extension does need to signal in ServerHello, it can update the TLS-Flags RFC at that time?

My vote would be to allow it in all places, and trust the process not to place flags that should be encrypted in payloads that aren’t, but either way, we need working group consensus.

Thanks

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Dec 2020 15:30:47 -0800

On Sat, Dec 5, 2020 at 7:05 AM Yoav Nir <[email-masked]> wrote:

> Hi.
>
> At IETF 108 a question was raised about The TLS Flags extension.  What
>  payloads on the server side can include this extension?
>
> The only one that is controversial here (I think) is ServerHello, because
> it is not encrypted.  Looking at the current list of extensions, I see that
> only 6 can go in ServerHello:
>
>    - password_salt
>    - tls_cert_with_extern_psk
>    - supported_ekt_ciphers
>    - pre_shared_key
>    - supported_versions
>    - key_share
>
>
> Of those, only one would be (if it hadn’t already been standardized) a
> candidate for the TLS-Flags extension: tls_cert_with_extern_psk.  The RFC
> describes it with “The “tls_cert_with_extern_psk" extension is
> essentially a flag to use the external PSK in the key schedule”.  I don’t
> think it’s unreasonable to think that at some point there’s going to be
> another flag-like extension that will need to be signalled in ServerHello.
>
> So the question for the group is, do we allow the flags extension (and the
> flags themselves) to be in ServerHello, or do we prohibit them for now, and
> if ever an extension does need to signal in ServerHello, it can update the
> TLS-Flags RFC at that time?
>
> My vote would be to allow it in all places, and trust the process not to
> place flags that should be encrypted in payloads that aren’t, but either
> way, we need working group consensus.
>

I agree with you that this is the right outcome.

-Ekr

> Thanks
>
> Yoav
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: David Benjamin <[email-masked]>
Date: Mon, 7 Dec 2020 11:16:02 -0500

>> The “candidates” are ServerHello, EncryptedExtensions, Certificate, and
Should CertificateRequest be in that list? By the way, the text for section
3 might need tweaking. The rules for request vs. response extensions are
almost client/server, but not quite. Probably better to cite or adapt the
text in RFC8446, section 4.2.

>> essentially a flag to use the external PSK in the key schedule”.  I
>> don’t think it’s unreasonable to think that at some point there’s going to
>> be another flag-like extension that will need to be signalled in
>> ServerHello.
>>
>> So the question for the group is, do we allow the flags extension (and
>> the flags themselves) to be in ServerHello, or do we prohibit them for now,
>> and if ever an extension does need to signal in ServerHello, it can update
>> the TLS-Flags RFC at that time?
>>

I also agree.

I suspect it doesn't hugely matter since ServerHello carries response
messages. Until and unless we define a ServerHello flags extension, the no
unsolicited extensions rule and the no empty flags rule mean ServerHello
flags are effectively prohibited unless the client implements such an
extension. So that means we can punt to TLS-flags RFC. (Whereas I think
we'll need to sort out CertificateRequest now to avoid compat issues.) But
it's easy to allow it now, and saves us having to think about whether it's
safe to do later.

David