]> Risks of Standalone ML-KEM in TLS 1.3 TU Dresden, Germany
muhammad_usama.sardar@tu-dresden.de
Security Transport Layer Security 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. ). We, therefore, kindly ask the chairs to initiate the FATT review of standalone ML-KEM in TLS. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction Readers are assumed to be familiar with , , and . We assert that the security considerations of are insufficient. We believe that symbolic and computational analysis of ML-KEM in the context of TLS is helpful here. We request that if the author has done any formal analysis, it would be very helpful to present the current state of formal analysis in the next meeting for discussion.
Motivation The draft aims to formally study the security of standalone ML-KEM in TLS 1.3 .
Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
  • Symbolic analysis: see SoK
  • Computational analysis: see SoK
Where ProVerif Proofs Break While ML-KEM looks like just a "trivial" addition, it makes changes as deep as the key schedule of TLS. It essentially replaces the key exchange by key encapsulation. While the former is symmetric, the latter is asymmetric. This symmetry is in terms of exchange of roles, and that the order does not matter. The proof in ProVerif is, therefore, utilizes this symmetry for the commutativity of the components gx and gy, where gx and gy represent the public keys of the endpoints. In ProVerif syntax: (see details here) Key encapsulation does not enjoy this commutativity property, or even an analogous symmetry argument. There is essentially only one endpoint (say client) which generates the key pair (dk,ek) where dk represents the secret decapsulation key and ek represents the public encapsulation key. As opposed to both endpoints sending their public keys gx and gy in the key exchange, only one of the endpoints (client in above example) sends the public encapsulation key and peer sends a ciphertext. This asymmetry breaks the existing proofs of TLS 1.3 in ProVerif and requires a new proof.
Current Status and Next Steps had an opposition of several (ca. 25 in our understanding) WG participants -- even more than the supporters (ca. 21 in our understanding) -- in the last WGLC. We see 2 possible options:
  • Continue tabletop discussions on subjective calculation of risks, costs, tradeoffs, etc., and keep burning WG energy.
  • Do some technical analysis using formal methods (symbolic and computational) to get a confirmation on the security of ML-KEM in the context of TLS and offer a statement for security considerations, and move on to more critical works like hybrid authentication.
We believe the former cannot resolve the dispute. We believe the latter may help.
"Cost" "Cost" has been presented on the list as the motivation for ML-KEM but no reference has yet been presented. We believe costs will depend on several factors -- including but not limited to implementation details and deployment scenario -- and it is quite subjective. There seems to be a need for a thorough study to understand the "cost." We invite the WG participants to perform this analysis and share the results with the WG.
ML-KEM: FATT Review We have formally requested the chairs to initiate the FATT process for . See this and this.
Expected Learning We believe formal methods can provide additional value for security considerations of this draft in order to maintain the high cryptographic assurance of TLS. Since we have no guarantee on whether ECDHE will break before ML-KEM, it seems appropriate to do thorough cryptographic analysis. We believe the Harvest Now, Decrypt Later (HNDL) attack applies equally well to standalone ML-KEM. Adversary can record all traffic and decrypt it when ML-KEM is broken (or probably it is already broken; who knows?)
  • As an example, it can help justify design choices, such as the preference for hybrids. It can help identify ways in which ML-KEM can break. It can also help identify all the assumptions under which the properties hold.
  • As a relevant data point in the context of standardization, LAKE WG has done formal analysis for EDHOC-PSK with KEM (ref).
  • Computational analysis (cf. SoK)-- using tools such as CryptoVerif -- seems like a reasonable approach to ensure security of ML-KEM in TLS, such as binding.
Formal Analysis (Work-in-progress) We have presented observation from our ongoing symbolic security analysis (cf. limitations in ) using ProVerif on the mailing list. We argue that in general:
  1. Migration from ECDHE to hybrid is security improvement.
  2. Migration from hybrid to standalone ML-KEM is security regression.
Hybrid PQ/T More formally, the property hybrid PQ/T should provide is: Hybrid preserves ECDHE, and adds ML-KEM as an additional factor. So as long as one of them is not broken, the system is secure. In particular, even if ML-KEM is completely broken, the system retains the security level of ECDHE.
Standalone PQ On the other hand, the formal property standalone PQ provides is: If ML-KEM is broken, the whole system is broken.
Comparison Leak out the ECDHE key from hybrid PQ/T and you get a standalone ML-KEM. Clearly, hybrid is in general more secure, unless ECDHE is fully broken, in which case it still falls equivalent to standalone ML-KEM, or in the hypothetical scenario that there is an implementation bug in the ECDHE part which is triggered only in composition.
Security Considerations The whole document is about improving security considerations. Like all security proofs, formal analysis is only as strong as its assumptions and model. The scope is typically limited, and the model does not necessarily capture real-world deployment complexity, implementation details, operational constraints, or misuse scenarios. Formal methods should be used as complementary and not as subtitute of other analysis methods.
IANA Considerations This document has no IANA actions.
References Normative References Module-lattice-based key-encapsulation mechanism standard National Institute of Standards and Technology (U.S.) ML-KEM Post-Quantum Key Agreement for TLS 1.3 SandboxAQ This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. The Transport Layer Security (TLS) Protocol Version 1.3 Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. TLS FATT Process IETF TLS WG Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Extensions to TLS FATT Process TU Dresden This document applies only to non-trivial extensions of TLS, which require formal analysis. It proposes the authors specify a threat model and informal security goals in the Security Considerations section, as well as motivation and a protocol diagram in the draft. We also briefly present a few pain points of the team doing the formal analysis which -- we believe -- require refining the process: * Provide protection against FATT-bypass by other TLS-related WGs * Contacting FATT * ML-KEM * Understanding the opposing goals * Response within reasonable time frame
Acknowledgments The research work is funded by German Research Foundation ("Deutsche Forschungsgemeinschaft.")
History -00
  • On popular demand, moved from to an independent I-D
  • Major change: added
  • Some minor clarifications