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

[Ilari Liusvaara <[e-mail]>]

On Tue, Aug 13, 2019 at 08:36:12PM -0500, Benjamin Kaduk wrote:
> 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.

Note that interpretation problems arise anyway if one has at least two
non-acknowledgeable flags:

- Client sends non-acknowledgeable flags X and Y.
- Server does not send flags / sends empty flags.

What do those mean? The case that come to mind are:

- Server does not support X nor Y.
- Server does not support X nor Y, but supports some other flags
  client did not send.
- Server supports X but not Y.
- Server supports Y but not X.
- Server supports both X and Y.


And server advertising some optional feature not releated to client
certificate or resumption is forbidden with regular extensions anyway.
But if one wanted such feature for flags, one would have to allow
"offer messages" (CH and CR) to contain empty flags, yes ("response
messages" (SH, EE, CT) do not need to be empty for that, and ST is
its own special case).


In general, if some extension only makes invalid into valid, one only
needs receiver acknowledgement of support (but may need sender
advertisment if protocol does not support recevier giving such
acknowledgement otherwise). If the extension alters meaning of valid,
one needs bidirectional negotiation anyway.


And there could be extensions that can alter what server sends before
server_hello (e.g., extended_alert that alters the alert format in
compatible way). Those are impossible to bidirectionally negotatiate,
but unidirectional capability advertisment is possible.



-Ilari