I just threw in a couple of PRs to align this I-D with 8446bis & 8447bis, but forgot to add this issue. I have corrected this now so that we won’t forget again: https://github.com/tlswg/tls-flags/issues/36
spt > On Mar 17, 2024, at 13:53, David Benjamin <[email protected]> wrote: > > Did this ever get resolved? I noticed that there was a draft-13 cut, but the > issue Jonathan pointed out was still there. > > Looking at Section 2 again, it's actually even goofier than the original > email suggests. Section 2 first says: > > > The FlagExtensions field contains 8 flags in each octet. The length of the > > extension is the minimal length that allows it to encode all of the present > > flags. Within each octet, the bits are packed such that the first bit is > > the least significant bit and the eighth bit is the most significant. > > This is LSB first. Then there's an example, which is also LSB first: > > > 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 > > So that's all consistent. But then the last paragraph of section 2 says: > > > Note that this document does not define any particular bits for this > > string. That is left to the protocol documents such as the ones in the > > examples from the previous section. 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. > > This says it's MSB first for some reason. But this is not only inconsistent, > but also redundant with the text at the start of section 2. It seems to me we > could simply delete the redundant text and move on: > > > Note that this document does not define any particular bits for this > > string. That is left to the protocol documents such as the ones in the > > examples from the previous section. Such documents will have to define > > which bit to set to show support. > > David > > On Wed, Sep 27, 2023, 17:50 David Benjamin <[email protected]> wrote: > 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 <[email protected]> > wrote: > Hi TLSWG, > > I'm working on implementing the TLS Flags extension, 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
