Re: [STDS-802-11-TGBT] Questions for IEEE 802.11-2026/1163r4
Hi Anuj,
On 7/13/26, 9:26 AM, "Anuj Dharap" <dharapanuj.ieee@xxxxxxxxx> wrote:
Hi Dan,
Thanks for your contribution. Here are my comments and questions as I mentioned during the AM1 meeting.
· I believe an element forward (extended length element) design does offer greater extensibility moving into the future for 802.11 and PQC generally. I think there is a genuine use case here for extended elements to be used in PQC and beyond.
Right, and that’s why extended length elements might be more appropriate for 11mf. Fields work and they can work for PQC. I am not saying they are the be-all-end-all, but they work for us here and now.
· Extra messages being sent now are payload-free and not really a problem, in the scheme of PQC they are virtually free.
I don’t know what “payload-free” means.
· EAP-first is DoS-resistant by design since expensive PQC operations are gated behind identity verification, which is architecturally sound especially at infrastructure scale
· PoW as discussed in the group + EAP-first provides a layered defense where PoW handles unauthenticated flooding and EAP would handle the authentication gate before PQC Key commitment
PoW can handle the DoS attacks. That’s the whole point. If one must do EAP first then the KEM+DH work then PoW is not really useful for 802.1X. This makes it useful.
· EAP-first also allows for mechanisms where with proper linkage between AS and AP, we can have true E2E Security Posture Remediation during authentication flow.
I fail to see how an established MLKEMss and DHss prevents any of that.
· Content Presence field has genuine future value for multi-KEM profile compositions (where 1 KEM is fixed in Security Profile and other is to be negotiated) - where payload structure is not fully implicit from frame position alone [similar to the
DH Group negotiation and ungraceful fallback issue seen now].
Again, if there is confusion such that a Content Presence field is necessary then the exchange has been poorly defined. And I would argue that a *security key exchange* that is so extensible^H^H^H^H^Harbitrary that its components get negotiated on the fly is
probably something we shouldn’t be doing in 802.11.
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
Best,
Anuj Dharap
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