Re: [STDS-802-11-TGBT] Large elements and 11-26/1265r0
Hi Dan,
Thank you for the comments.
I agree that the current normative text document defines the base Large
Element construct, but does not yet apply it throughout the 11bt D0.3 text needed to remove PQC element fragmentation. That update is needed. I will use 11-26/1163 as a reference/checklist and update the normative text to identify the concrete D0.3 changes
needed for this proposal.
On the TLV point: I agree that 9.4.4 is relevant. REVmf already defines TLV as a type/length/value format, and 9.4.4 defines TLV encodings in
Management frame contexts, including discard behavior for unknown, unspecified, or reserved Type values. However, the existing 9.4.4 TLV format uses a 1-octet Type and a 1-octet Length field.
The construct in 11-26/1265 is intended to address the larger ID namespace
and larger length requirement. It is currently named “Large Element,” but functionally it is a scoped type-length-delimited large-object format with a 2-octet Large Element ID and 2-octet Large Element Length. It is valid only where a frame format or negotiated
feature explicitly permits a Large Element List, and its ID namespace is independent of the legacy Element ID namespace.
I will add this clarification to the deck as well, so that the group can discuss both the Large Element naming and the possible 9.4.4 TLV alignment without losing the main goal (removing PQC element fragmentation from the
11bt D0.3 authentication exchanges asap).
regards
Anirban
From: Harkins, Dan <daniel.harkins@xxxxxxx>
Date: Tuesday, 30 June 2026 at 19:00
To: Anirban Karmakar (akarmaka) <akarmaka@xxxxxxxxx>
Cc: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>
Subject: Large elements and 11-26/1265r0
Hi Anirban,
As I mentioned on the teleconference today, Large Elements are a very interesting way of addressing the problem of fragmenting our PQC data in the 11bt draft. But 11-26/1265r0 does not do that. It’s merely a proposal to add the functionality, it does not
actually solve the problem.
If you desire to use Large Elements as a solution to 11bt’s fragmentation problem there is a considerable amount of work necessary to 11-26/1265 in order to actually use them in the draft to avoid element fragmentation. Also, as mentioned, you can use 11-26/1163
as a guide to identify the places you will need to change text to add this capability. I do not claim 11-26/1163 is 100% solid though and I may have missed some places so please go through the 11bt draft and ensure that every place that needs changes gets
changed.
There is a strong desire to start certifying PQC protocols in 802.11 (specifically the 802.1X exchange for CNSA 2.0) and if people start certifying our draft then the text is going to be etched in stone and, barring some massive security issue, unchangeable.
It is imperative that we fix this element fragmentation issue before we produce draft 1.0. With that in mind, I look forward to your proposal to solve this problem using Large Elements.
There was also a mention of using TLVs (section 9.4.4 of the real baseline). That’s got potential too. But we need a submission that identifies the exact text changes to 0.3 necessary to use TLVs to get rid of our PQC fragmentation.
Let 100 flowers bloom! Let 100 schools of thought compete! But let’s get those flowers blooming. We need concrete proposals or we will be stuck with fragmenting encapsulation keys and ciphertexts forever and that would be regrettable.
Regards,
Dan.
--
“the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane.” – Marcus Aurelius
To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1