On Sat, Dec 5, 2020 at 7:05 AM Yoav Nir <ynir.i...@gmail.com> 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 “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.
>

I agree with you that this is the right outcome.

-Ekr


> Thanks
>
> Yoav
>
> _______________________________________________
> 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

Reply via email to