Subject: [TLS] Can flags be responded to with an extension?

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Apr 2022 10:56:49 -0700

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?
-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 13 Apr 2022 21:44:06 +0300

> should explicitly allow it.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 13 Apr 2022 15:51:31 -0700

> should explicitly allow it.

In my head this was already disallowed.  I couldn't swear to whether
we actually talked about it previously or not, though.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Apr 2022 15:53:34 -0700

> we actually talked about it previously or not, though.

That's certainly possible, though I couldn't find text one way or another

-Ekr