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.
regards,
Nikos
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
