Re: [TLS] A flags extension

[Hubert Kario <[e-mail]>]

On Wednesday, 27 March 2019 14:42:49 CET Martin Thomson wrote:
> Why not go all in - make this a byte string and start from 0x80 in the first
> byte.  When we define the 9th flag, we add another byte.  Then you have up
> to 2040 flags (though it might pay to split the space before that).
> 
> struct {
>   opaque<1..255> flags;
> } Flags;
> 
> Otherwise, the first adopter of this pays 10 bytes where they would
> previously have paid 4.  Obviously there is a network effect at the third. 
> Since I'm writing a draft that will aim to depend on this, I have a vested
> interest in using this.

this will be the only place with a bit mask in TLS, I have serious doubts 
about the correctness of code that will handle this stuff
 
> If you wanted to make it more attractive to me, then maybe porting some of
> the existing flags across might make it more appealing.

what about making sure that the legacy and flags remain in-sync? we will have 
to send the legacy encoding for many years to come, so only thing it would 
possibly reduce the size of is ServerHello or EncryptedExtensions

> On Wed, Mar 27, 2019, at 13:08, Yoav Nir wrote:
> > > On 27 Mar 2019, at 12:26, Daniel Kahn Gillmor <[e-mail]>
> > > wrote:> > 
> > > On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote:
> > >> Right. What about defining a set of extensions (e.g., 2 extensions) of
> > >> flags as:
> > >> 
> > >> struct {
> > >> 
> > >>  uint64 flags;
> > >> 
> > >> } Flags;
> > > 
> > > If we're going to be doing this kind of bit-shaving, this is the way to
> > > go, starting with a single CommonFlags extension -- and maybe even a
> > > uint32 or uint16, with the bitfield registry under tight WG control. If
> > > we exhaust that space, then we just define a CommonFlags2 extension.
> > > 
> > > If someone wants an experimental boolean extension to play with, they
> > > can always use an empty extension. They can apply for a bit in
> > > CommonFlags if they find that the compactness is warranted.
> > 
> > OK. You got me convinced.
> > 
> > In the spirit of revising quickly and revising often, I’ve uploaded
> > version -01:
> > 
> > HTML: https://datatracker.ietf.org/doc/html/draft-nir-tls-tlsflags
> > DIFF: https://www.ietf.org/rfcdiff?url2=draft-nir-tls-tlsflags-01
> > 
> > Yoav
> > 
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic