Oh, perfect! I was trying to find the GitHub repo to make the PR but missed it somehow. Here's a PR: https://github.com/tlswg/tls-flags/pull/37
On Mon, Mar 18, 2024 at 5:01 PM Sean Turner <[email protected]> wrote: > 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
