Re: [TLS] A flags extension

One option for a bitstring could be to encode it in little endian and
truncate 0 bytes at the end of the encoding.

On Tue, Mar 26, 2019 at 10:50 AM Yoav Nir <ynir.ietf@gmail.com> wrote:

>
>
> > On 26 Mar 2019, at 10:35, Nikos Mavrogiannopoulos <nmav@redhat.com>
> wrote:
> >
> > On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote:
> >>> On 26 Mar 2019, at 9:06, Martin Thomson <mt@lowentropy.net> wrote:
> >>>
> >>> This needs more space for each flag.  8 bits is a pretty small
> >>> space.  If you are concerned with the size of the result, we have
> >>> some variable-length integer encodings you could try.
> >>
> >> Ah, the beautiful variable length encodings.  Like:
> >>
> >> - 0x00 - 0xBF - for standards-action allocations
> >> - 0xC0,0x00 - 0xEF,0xFF - for non-standards track
> >> - 0xF0,0x00 - 0xFF,0xFF - for private use among consenting parties.
> >> Are we really worried that we’re going to have more than 255 optional
> >> features for TLS?
> >
> > Given that adding an extended flags extension which can hold even more
> > flags is also easy, the 255-optional features do not seem so limited.
> >
> > Going into the extension itself, the array FlagExtensionType seems to
> > be the TLS-way to define such variable, but flags are easier, more
> > efficient to parse, and take less space if they are bits on an integer
> > value (32-bit or 64-bit). Have you considered a simpler structure like
> > that?
> >
> > struct {
> >   uint64 flags;
> >   uint64 ext_flags1;
> >   uint64 ext_flags2;
> >   uint24 ext_flags3;
> >   uint16 priv_flags;
> > } Flags;
> >
> > The advantage is that it can carry the same information with much less
> > bytes on the wire and it is easier to parse in low level languages.
> >
> > The disadvantage is that an extension flag would now need to specify
> > the bit it occupies _and_ the particular element it is set to.
>
> I thought about that. I guess it depends on how many of these optional
> features we expect to be declared at the same time.
>
> With the current way the draft is written, if the client supports 12 such
> extensions, the extension takes 16 bytes.  With a bitstring, it’s always
> the same length. so we’d need 36 bytes for a 256-bit space. If the client
> supports 100 extensions, my encoding takes 104 bytes while the bitstring is
> still 36 bytes.
>
> The question is which is more likely?
>
> Yoav
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>