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 <d...@fifthhorseman.net>
> > > 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
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
