Hi Yoav, Thanks for doing this. I personally prefer the flag choice you have.
I think that you need to move from CH,SH,EE (which has a weird duplication that might be problematic), to CH, EE, CR, C. Critically, I don't think that you want the ServerHello to carry any of these. Flags are generally not used for key exchange, and I think that we can use the old school approach if that comes up, or define a different flags extension. The requirement for the server (or really the responder) to echo the client's flags seems like it might have some problems. From an implementer perspective, I strongly prefer to have this processed in exactly the same way as an empty extension, which is sometimes echoed and sometimes not as needs dictate. You can see with the case of a flag sent in ClientHello and responded to by the server in either EncryptedExtensions or Certificate. Requiring that flags are echoed in both contexts might be confusing. Cheers, Martin On Wed, Jul 24, 2019, at 00:32, Yoav Nir wrote: > Hi. > > Following today’s session, I’ve updated and submitted the draft. > > It contains the proposal from slide #5 in my presentation. > > It does not contain any fancy way of reserving bits for future popular > extensions. > > It uses a single numbering of the flags, not the more efficient > separate numbering per context (CH, SH, EE, CH-in-CTLS) > > I believe such bikeshedding can be done after adoption. Just so long as > we don’t make it of asbestos. [1] > > Yoav > > [1] It was never about the color of the bike shed, but about the > material: https://en.wikipedia.org/wiki/Law_of_triviality#Examples > > > > Begin forwarded message: > > > > *From: *internet-dra...@ietf.org > > *Subject: **New Version Notification for draft-nir-tls-tlsflags-02.txt* > > *Date: *23 July 2019 at 23:22:50 GMT-4 > > *To: *"Yoav Nir" <ynir.i...@gmail.com> > > > > > > A new version of I-D, draft-nir-tls-tlsflags-02.txt > > has been successfully submitted by Yoav Nir and posted to the > > IETF repository. > > > > Name: draft-nir-tls-tlsflags > > Revision: 02 > > Title: A Flags Extension for TLS 1.3 > > Document date: 2019-07-22 > > Group: Individual Submission > > Pages: 6 > > URL: https://www.ietf.org/internet-drafts/draft-nir-tls-tlsflags-02.txt > > Status: https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/ > > Htmlized: https://tools.ietf.org/html/draft-nir-tls-tlsflags-02 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-nir-tls-tlsflags > > Diff: https://www.ietf.org/rfcdiff?url2=draft-nir-tls-tlsflags-02 > > > > Abstract: > > A number of extensions are proposed in the TLS working group that > > carry no interesting information except the 1-bit indication that a > > certain optional feature is supported. Such extensions take 4 octets > > each. This document defines a flags extension that can provide such > > indications at an average marginal cost of 1 bit each. More > > precisely, it provides as many flag extensions as needed at 4 + the > > order of the last set bit divided by 8. > > > > > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
