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

[Eric Rescorla <[e-mail]>]

On Mon, May 9, 2022 at 8:43 AM Benjamin Kaduk <bkaduk=
[e-mail]> wrote:

> On Mon, May 09, 2022 at 06:10:43PM +0300, Yoav Nir 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?
>
> 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.
>

Hmm... I don't think this is really the right approach at this stage.

The situation here is that the explicit text is ambiguous. If this were
already an RFC, we would need to try to determine what it meant so that we
could agree how implementations ought to be behaving. In that case, yes, we
would look at this kind of language to attempt to resolve the ambiguity.

However, this is not an RFC and so our task is to make the specification as
unambiguous as possible. At this stage, we should be asking what the
*right* answer is, not what the one that most closely matches the current
ambiguous text. My argument is that the right answer is the one that most
closely embodies the broader goal of saving bandwidth for low-information
signals, in this case the signal that the client could process a given
server extension. So, yes, the client's extension contains no interesting
information but the server's does, which, I think, is consistent with this
text, even if, arguably, it's not the better reading.

I can certainly see arguments against forbidding this practice for
technical reasons (e.g., simplicity), but, again, then the specification
should just say so.

-Ekr