On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir wrote: > > > > On 14 Apr 2022, at 1:51, Benjamin Kaduk > > <bkaduk=40akamai....@dmarc.ietf.org> wrote: > > > > 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. > > > > In my head this was already disallowed. I couldn't swear to whether > > we actually talked about it previously or not, though. > > I’m pretty sure we haven’t discussed this (or at least, I wasn’t in the > room). In my head it’s also disallowed. In the text, it’s not explicitly > disallowed, but the text does talk about response flags that are in flag > extensions, not about responses that are in other extensions or other > messages. So implicitly disallowed?
I think the description in the abstract of the target class of extension as those "that carry no interesting information except the 1-bit indication that a certain optional feature is supported" also implicitly disallows response bodies. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
