Hi, On 03.04.26 21:13, Stephen Farrell wrote:
On 03/04/2026 19:53, David Benjamin wrote:I do not think this subjective risk management question of hybrids is worthy of all of this drama and we should just accept and consider this feedback.For me, and some others, the question is worthy of the drama, based on concerns that some issues might arise with newer algs or their implementations. Seems like a matter of safety really, until one is convinced of the robustness of pure PQ algs and code. You may well be, but I'm not yet.
Completely agree with Stephen. If David is labeling paying due diligence to maintain high-assurance of TLS as "drama", then I'm fine to pay this cost. Unfortunately, I have played my role in two "dramas" in the past on the TLS list (see PS) and based on my preliminary working of this pure ML-KEM thingy, and to the best of my current understanding, knowledge and belief, I am convinced that this "drama" is fully worth it.
IMHO, unless some technical rationale is provided by IEEE 802.11, this LS should just be read as 'someone somewhere in the world would like to use pure ML-KEM' and TLS WG should not serve as a /printing press/ for such requests. Codepoints are assigned and I believe TLS WG is done with its job. I believe we should just give "no objection response" to IEEE 802.11 to publish it themselves if they have any urgency. If we are to publish it within TLS WG, we should maintain high integrity in security considerations.
I would have been happy if WG was moving towards mentioning the risks of pure ML-KEM that several folks have highlighted in the WGLC. I would also have been happy if some strong and genuine motivation was mentioned in the draft for security degradation from hybrid to pure ML-KEM. Unfortunately, the exact reverse of both is happening in the repo (e.g., PR#14) and recent commits have surprisingly removed the whole motivation altogether. I have also provided significant feedback in the WGLC. None of that has been addressed in the draft. This is not acceptable to me.
FWIW, as I mentioned a potential path forward, I believe we should do a dedicated effort to mention all risks in security considerations and then dispatch this draft to experts in CFRG Review Panel to get their attestation on the security considerations. We should also recommend hybrids first (draft-usama-tls-ecdhe-mlkem-update).
Sincerely,-Usama (a security paranoid 🙂 who is deeply in love with TLS, and as always, expressing my personal opinion in my personal capacity, which the WG is absolutely free to ignore and trash. However, I do know my rights and I will go for appeal if I feel that the final draft ignores critical security considerations or puts the community at significant risk)
PS:I did a "drama" together with Mariam and Tuomas in Feb 2025 [0], which was later shown to be practical with high-severity in BadRAM [1], wiretap.fail [2], and TEE.fail [3] in just /10 bucks/.
I did another "drama" together with Slava and Jean-Marie last month [4], which has been acknowledged almost /word-by-word/ (see "Limitations and the relay attack" in [5]) by leading vendors in the domain resulting in a *high-severity* (7.8/10) security advisory [6] and high-severity (7.5/10) CVE (*CVE-2026-33697*) [7].
So yes, this pure ML-KEM thingy is nothing less than the above two to me and absolutely worth another "drama" to me.
PPS:Following my first email upstream in this thread, a senior WG participant and my mentor has reached out to me off-list with CC to some VIPs about potential ambiguity in my request to IEEE 802.11 WG chair and LO for further information. So I want to clarify any potential misunderstanding:
I strongly believe it is well-known by default but just as a global clarification, everything I say on IETF/IRTF lists is by default purely /my personal opinion in my personal capacity/, unless explicitly mentioned otherwise, e.g., by saying "as co-chair of Open TRE at GA4GH", which in the whole last year of co-chairing, I never needed to do on the IETF/IRTF lists. Just an aside: Since I am on this topic, for presentations, if something is discussed and agreed upon in some other SDO, it is explicitly mentioned as affiliation on the first slide (e.g., [8]). Absent any SDO affiliation, it should simply be interpreted as coming from me (as a security paranoid) and my co-authors mentioned on the first slide (if applicable).
[0] https://mailarchive.ietf.org/arch/msg/tls/Jx_yPoYWMIKaqXmPsytKZBDq23o/ [1] https://badram.eu/ [2] https://wiretap.fail/ [3] https://tee.fail/ [4] https://mailarchive.ietf.org/arch/msg/tls/8lyqHh9y7_Lv6b1iXhpUqYrp0M0/[5] https://web.archive.org/web/20260227160554/https://www.ultraviolet.rs/blog/tee-tls-privacy/
[6] https://github.com/ultravioletrs/cocos/security/advisories/GHSA-vfgg-mvxx-mgg7
[7] https://nvd.nist.gov/vuln/detail/CVE-2026-33697[8] https://datatracker.ietf.org/meeting/125/materials/slides-125-tls-tls-fatt-extensions-00
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
