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

[Benjamin Kaduk <[e-mail]>]

Hi Ekr,

On Mon, May 09, 2022 at 08:56:26AM -0700, Eric Rescorla wrote:
> 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

Yes.  You've convinced me that we need to be (more) explicit one way or the other.

Please treat my remark as a contribution to enumerating places in the document
that would need to change if we were to allow responses outside of the flags
extension.

-Ben

> 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