Re: [TLS] TLSFlags ambiguity

Nice catch! I agree those don't match. I think bit zero should be the
least-significant bit. That is, we should leave the examples as-is and then
fix the specification text.

Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no
inherent order to bits in memory, so the most natural order is the power of
two represented by the bit. Put another way, everyone accesses bit N by
ANDing with 1 << N and that's least-significant bits first. I can think of
a couple systems (DER, GCM) that chose to order bits most-significant first
and both have caused endless confusion and problems. (It's particularly bad
for GCM which is actually representing a polynomial, but then messed up the
order. Let's not repeat this blunder.)

On Fri, Sep 15, 2023 at 1:37 PM Jonathan Hoyland <jonathan.hoyland@gmail.com>
wrote:

> Hi TLSWG,
>
> I'm working on implementing the TLS Flags extension
> <https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-12>, and I
> just wanted to clarify a potential ambiguity in the spec.
>
> In Section 2 the spec says:
> Such documents will have to define which bit to set to show support, and
> the order of the bits within the bit string shall be enumerated in network
> order: bit zero is the high-order bit of the first octet as the flags field
> is transmitted.
>
> And also gives the example for encoding bit zero:
> For example, if we want to encode only flag number zero, the FlagExtension
> field will be 1 octet long, that is encoded as follows:
>
>    00000001
>
> In which it seems that the low-order bit of the first octet represents zero.
>
> I have no preference either way, but when transmitted on the wire, should flag 0 be transmitted as
>
> 0x01 or 0x80?
>
> Regards,
>
> Jonathan
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>