As all (OK, both) of the responses have been supportive, I have created a pull request:
https://github.com/tlswg/tls-flags/pull/5 <https://github.com/tlswg/tls-flags/pull/5> Yoav > On 5 Dec 2020, at 17:04, 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. > > Thanks > > Yoav >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
