Hi all,On popular demand, I've moved around ML-KEM from draft-usama-tls-fatt-extension [0] to a draft of its own.
If you have read my FATT draft [0], there is only one new -- just two-minutes read -- section (Sec. 2.1), but it is the most important one, where I show precisely where my [1] (and Karthik et al.'s [2]) existing TLS 1.3 proofs in ProVerif break and why FATT review is necessary. I believe this is sufficient justification for FATT review.
I am looking for constructive feedback on the technical objection in Sec. 2.1. Please do not go off-topic. Thank you!
For off-topic items, issues and PRs are welcome at [3]. I will ask for a slot to present it in Vienna. Sincerely, -Usama [0] https://datatracker.ietf.org/doc/draft-usama-tls-fatt-extension/ [1] https://github.com/CCC-Attestation/formal-spec-id-crisis [2] https://github.com/inria-prosecco/reftls [3] https://github.com/muhammad-usama-sardar/risks-of-mlkemPS: [0] is yet to be updated. Everything on ML-KEM will be removed from there in the next version.
-------- Forwarded Message --------Subject: New Version Notification for draft-usama-tls-risks-of-mlkem-00.txt
Date: Fri, 15 May 2026 04:50:33 -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-00.txt has been
successfully submitted by Muhammad Usama Sardar and posted to the IETF repository. Name: draft-usama-tls-risks-of-mlkem Revision: 00 Title: Risks of Standalone ML-KEM in TLS 1.3 Date: 2026-05-15 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/archive/id/draft-usama-tls-risks-of-mlkem-00.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-00.htmlHTMLized: https://datatracker.ietf.org/doc/html/draft-usama-tls-risks-of-mlkem
Abstract: We attest that standalone ML-KEM in TLS 1.3 breaks the existing formal proofs of TLS in state-of-the-art symbolic security analysis tool, ProVerif. We also attest that from a formal analysis perspective, this is a much bigger change than RFC8773bis, which indeed went for FATT review (cf. [TLS-FATT]). We, therefore, kindly ask the chairs to initiate the FATT review of standalone ML-KEM in TLS. The IETF Secretariat
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
