Hi folks,This is the last version for the TLS WG as a formal check to see if there are any objections to taking it to the Independent Submissions Editor (ISE) path, or if anything else is required from the WG for ISE path. I believe the draft has served its purpose of getting an assurance on integration of ML-KEM in TLS in ProVerif. I also sincerely hope it helps us avoid repeating the arguments without adding any new insights, so that the WG can actually move forward to some technical discussions.
I believe the separate draft for ML-KEM was helpful; we were able to focus on this matter and Nadim got the proof done quickly. Special thanks to Nadim, Yaakov, and Ilari for their help and feedback.
IIUC, the ISE seems to welcome such a submission [0,1]. Specifically, in my reading, [0] seems to mention KEMs, and [1] seems to welcome opinions.
Correspondingly, this version is a major reframing to cover: 1. Opinions of IETF participants (Sec. 6) -- I say IETF rather than TLS WG because I took a few points from IETF LC of ML-DSA (some arguments applied for ML-KEM too). 2. Minimal implementation guidance for hybrids (Sec. 5) -- bundle of thanks to Songbo who has kindly provided this section in a couple of PRs. 3. Summary of formal methods work (Sec. 3,4) -- needs some more work for reframing Any further contribution or feedback is very welcome.I would have liked the draft to be more neutral than it currently is, but despite every version since -00 explicitly requesting "costs" analysis [2], no quantitative data was provided. The only concrete cost I found was 32 bytes compared to ~1K bytes [3]. If there are additional analyses or data that should be considered, I would appreciate any specific pointers.
If you believe some of your arguments are under-represented or inaccurately characterized, please submit a precise and concise PR [4].
This concludes my intervention. Best, -Usama[0] https://mailarchive.ietf.org/arch/msg/last-call/xZpR7cCI9rhBvrZIohUQujm2a2c/
[1] https://mailarchive.ietf.org/arch/msg/last-call/Y_kcyW32gVodKQuaN8p5PDwMy9w/
[2] https://www.ietf.org/archive/id/draft-usama-tls-risks-of-mlkem-00.html#section-2.2.1-2
[3] https://www.ietf.org/archive/id/draft-usama-tls-risks-of-mlkem-03.html#section-6.8
[4] https://github.com/muhammad-usama-sardar/risks-of-mlkem -------- Forwarded Message --------Subject: New Version Notification for draft-usama-tls-risks-of-mlkem-03.txt
Date: Thu, 11 Jun 2026 11:06:07 -0700 From: [email protected]To: Muhammad Sardar <[email protected]>, Muhammad Usama Sardar <[email protected]>
A new version of Internet-Draft draft-usama-tls-risks-of-mlkem-03.txt has been
successfully submitted by Muhammad Usama Sardar and posted to the IETF repository. Name: draft-usama-tls-risks-of-mlkem Revision: 03 Title: Analysis of Hybrid Key Exchange and Standalone ML-KEM in TLS 1.3 Date: 2026-06-11 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/archive/id/draft-usama-tls-risks-of-mlkem-03.txt Status: https://datatracker.ietf.org/doc/draft-usama-tls-risks-of-mlkem/ HTML: https://www.ietf.org/archive/id/draft-usama-tls-risks-of-mlkem-03.htmlHTMLized: https://datatracker.ietf.org/doc/html/draft-usama-tls-risks-of-mlkem Diff: https://author-tools.ietf.org/iddiff?url2=draft-usama-tls-risks-of-mlkem-03
Abstract: The draft presents _symbolic_ and _computational_ analysis of hybrid key exchange and standalone ML-KEM. In our observation, we believe that hybrid key exchange is preferable over standalone ML-KEM until a powerful CRQC exists which breaks *all* the bits of pre-quantum. This draft also offers opinions of the IETF participants and some preliminary discussion to help the developers and policymakers make informed choices. Finally, it offers minimal implementation guidance for hybrids. The IETF Secretariat
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
