On Sat, Dec 5, 2020 at 6:31 PM Eric Rescorla <e...@rtfm.com> wrote: > > > 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. >> > 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.
> 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. > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
