Hi Nehru,
On 3/26/26, 2:04 PM, "Nehru Bhandaru" <nehru.bhandaru@xxxxxxxxxxxx> wrote:
Thanks Dan. Interesting article.
Looks like it is not a debate just in IEEE 802.11/bt. Still IETF and other folks in the industry are debating and according to the article
“It is true that 0x11EC is not marked as Recommended, mostly because it started out as an experimental combination that then somehow ended up as the thing everybody was doing, and while lots of digital ink was spilled on whether or not it should be recommended, nobody updated the flag before publishing the RFC. (technically the RFC is not published yet, but the rest is pretty much formality, and the flag is unlikely to change) So yes, technically the IETF did not recommend a hybrid algorithm”
In IETF ID, it is not recommended (https://www.ietf.org/archive/id/draft-kwiatkowski-tls-ecdhe-mlkem-03.txtz) but X25519 + ML KEM 768 (0x11EC) is still provided and it is marked as recommended in cloudefare (https://developers.cloudflare.com/ssl/post-quantum-cryptography/)
That’s the point! Someone who implements this—namely Cloudflare—can recommend anything they want _in their product_ even if it differs from the specification/standard. And anyone in 802.11bt who wants to implement anything we end up specifying can also do what they want. We cannot force a vendor to do anything. We can specify an MTI for interoperability purposes but that’s just to make sure your code works, it means nothing about how this gets deployed.
So the argument of a certain handset vendor that “we do not want to do pure ML-KEM” is fine. Don’t. No one is forcing you to. But when you want to stop anyone else from implementing pure ML-KEM it’s time for the gif—“you’re not my supervisor”.
Deploying a pure ML-KEM implementation, or even doing ML-KEM-512, involves a conscious effort. And both sides have to agree to do it. If this conflicts with what your “security group” says then by all means, don’t do it. But no one in TGbt, and no “security group” at any affiliated company of any participant, is qualified to tell me what I can and cannot do with post quantum 802.11. All they can legitimately say is “we do not want…” which is fine. Then don’t, no one is forcing you. But have the courtesy of not forcing your wants on everyone else.
Not being a cryptographer, logically speaking, if x is the security level provided by pure ML KEM and y is the security level provided by the classical DH, can we say x + y >= y, assuming that classical does not reduce the security of the pure ML KEM… there is nothing to lose with hybrid? Granted, according to the article, NSA uses only pure ML KEM 1024…
I think the guarantee is that the sum of the security is at least as secure as either of them. As far as “nothing to lose”, well there’s payload bloat, more messages to do both exchanges, and more fragments of messages since they’re bigger. Your evaluation of “nothing to lose” may differ from someone else’s.
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
- Nehru
On Wed, Mar 25, 2026 at 4:37 PM Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Just ran across an interesting blog post by Sophie Schmieg, a cryptographer at Google. It discusses pure ML-KEM vs hybrid and dispels some of the myths that appeared in TGbt when we started discussing things beyond the simple “allowed” security profile—namely, “It will cause a downgrade attack!” and “it’s not secure enough”. Also, there is a hilarious gif which is the appropriate response to demands for “mandatory to implement” algorithms that you don’t want to support.
Enjoy: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/
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
