Re: [TLS] I-D Action: draft-ietf-tls-tlsflags-00.txt

[Benjamin Kaduk <[e-mail]>]

On Tue, Aug 13, 2019 at 06:23:54PM -0700, Watson Ladd wrote:
> On Tue, Aug 13, 2019 at 6:12 PM Benjamin Kaduk <[e-mail]> wrote:
> >
> > On Tue, Aug 13, 2019 at 06:03:32PM -0700, Watson Ladd wrote:
> > > On Tue, Aug 13, 2019 at 6:00 PM Benjamin Kaduk <[e-mail]> wrote:
> > > >
> > > > On Mon, Aug 12, 2019 at 09:25:19PM +0300, Ilari Liusvaara wrote:
> > > > > On Mon, Aug 12, 2019 at 10:48:55AM -0700, [e-mail] wrote:
> > > > I think you need to send it in at least one protocol "response", to
> > > > confirm support for the extension, even if none of the flags offered
> > > > require confirmation/echo individually.
> > >
> > > I'm not sure this is the case: if in the future we define flags, then
> > > what is the difference between not understanding any flag and not
> > > understanding the extension?
> >
> > Nothing -- the difference is between understanding the "please frobnitz
> > my baddle" flag and not understanding it (or the extension, for that
> > matter).  If "please frobnitz my baddle" is defined such that it appears
> > in the ClientHello and if the server supports the extension, the server
> > has the option to send a Thwarp handshake message to the client at any
> > time post-handshake if the server detects its imminent demise, then the
> > client that observes "I didn't get a Thwarp" cannot distinguish between
> > "the server doesn't support the extension" and "the server supports the
> > extension but is unaware of an imminent demise".
> 
> But then you would send the flag back in the Server Hello, no?

If you define the extension with those semantics, yes.  We've in the
past wanted to reserve the option of having, well, the
post_handshake_auth semantics, where the client indicates a capability
and the server can optionally send a new protocol message.  Would it be
a huge loss if we didn't have that ability for things that want to use
the flags extension?  No.

-Ben