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

[Eric Rescorla <[e-mail]>]

Well, sounds like it's an open issue

My view is that it should be explicitly allowed, but I don't feel that
strongly about it. I do, however, feel strongly that the draft should say
explicitly one way or the other.

On Mon, May 9, 2022 at 8:10 AM Yoav Nir <[e-mail]> wrote:

>
>
> > On 14 Apr 2022, at 1:51, Benjamin Kaduk <bkaduk=
> [e-mail]> 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?
>
> Yoav
>
>