On Tue, Aug 13, 2019 at 6:12 PM Benjamin Kaduk <bka...@akamai.com> 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 <bka...@akamai.com> wrote: > > > > > > On Mon, Aug 12, 2019 at 09:25:19PM +0300, Ilari Liusvaara wrote: > > > > On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-dra...@ietf.org > > > > wrote: > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > > directories. > > > > > This draft is a work item of the Transport Layer Security WG of the > > > > > IETF. > > > > > > > > > > Title : A Flags Extension for TLS 1.3 > > > > > Author : Yoav Nir > > > > > Filename : draft-ietf-tls-tlsflags-00.txt > > > > > Pages : 6 > > > > > Date : 2019-08-12 > > > > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > > > > > > > > > There are also htmlized versions available at: > > > > > https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00 > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00 > > > > > > > > Two things: > > > > > > > > > > > > 1) uint8 flags<0..31>; > > > > > > > > That adds an extra byte that is not technically necressary (because > > > > extensions have lengths anyway) and limits number of flags to 248 > > > > (which might be enough). > > > > > > > > And I do not think the length of flags field can be 0 (if it would > > > > > > 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? > > Does that help? > > -Ben -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
