On Tue, 2019-03-26 at 10:49 +0100, Yoav Nir wrote:
> > On 26 Mar 2019, at 10:35, Nikos Mavrogiannopoulos <n...@redhat.com>
> > wrote:
> >
> > On Tue, 2019-03-26 at 10:11 +0100, Yoav Nir wrote:
> > > > On 26 Mar 2019, at 9:06, Martin Thomson <m...@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.
Right. What about defining a set of extensions (e.g., 2 extensions) of
flags as:
struct {
uint64 flags;
} Flags;
That way there are 128 different flags available for assignment with a
cost is 4+8-bytes for every 64 flags.
regards,
Nikos
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
