On Wed, Apr 13, 2022 at 10:56:49AM -0700, Eric Rescorla wrote: > Consider the case where the client wants to offer some capability that > the server then responds to with real data, rather than just an > acknowledgement. > > For instance, supposing the SCT extension from RFC 6962 did not exist, > the client would want to indicate support in CH and the server would > send the SCT in CERT, but this extension would need to be non-empty > and hence not a flag. draft-ietf-tls-tlsflags-09 seems a bit > uncelar on this point (unless I'm missing it) but I think we > should explicitly allow it. > > Thoughts?
There is actually precedent for stuff like this (even if it is a nasty hack): The TLS_EMPTY_RENEGOTIATION_INFO_SCSV ciphersuite. The reply to that is the renegotiation_info extension, even if that extension was not present in the client hello. However, that one is not exactly pleasant to implement in TLS library, Looking at source of my TLS library, it has some magic hacks in order to support parsing client hello with TLS_EMPTY_RENEGOTIATION_INFO_SCSV. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
