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