> 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.
The question is which is more likely?
Yoav
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
