> On 12 Aug 2019, at 21:25, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
>
> On Mon, Aug 12, 2019 at 10:48:55AM -0700, internet-dra...@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Transport Layer Security WG of the IETF.
>>
>> Title : A Flags Extension for TLS 1.3
>> Author : Yoav Nir
>> Filename : draft-ietf-tls-tlsflags-00.txt
>> Pages : 6
>> Date : 2019-08-12
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tls-tlsflags-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-00
>
> Two things:
>
>
> 1) uint8 flags<0..31>;
>
> That adds an extra byte that is not technically necressary (because
> extensions have lengths anyway) and limits number of flags to 248
> (which might be enough).
I hope 248 is enough...
> And I do not think the length of flags field can be 0 (if it would
> be, one could just omit the extension).
There could be a future flag that the server sends unsolicited
(client-auth-required?). It’s important for the client to show support for the
flags extension to make sure that it understands what the server is sending.
Depends on how we define the semantics in the draft.
>
>
> 2) I think the bit order within octets should be reversed
>
> That is, pack flags so that 0 is LSB of first octet, 7 is MSB of
> first octet, 8 is LSB of second octet and so on.
>
> Then one can read status flags by index with code like:
>
> fn read_flag(flags: &[u8], idx: usize) -> bool
> {
> *flags.get(idx/8).unwrap_or(&0) >> idx%8 & 1 != 0
> }
>
> (That code will also happily handle out-of-array flags by reading
> them as false.)
Makes sense. I get caught up in visualizing computer memory and protocol
messages as a string of bits written from left to right.
> -Ilari
>
> _______________________________________________
> 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
