Re: [TLS] TLSFlags ambiguity

[David Benjamin <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> 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 <
> [e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls
>
>