]> 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. In this draft, we show exactly where the ProVerif proofs break, namely transition from symmetric DHKE to asymmetric KEM. More specifically, the existing proofs of TLS in ProVerif are based on commutativity property, whereas commutativity does not apply to standalone ML-KEM in TLS. 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, formally request the chairs to initiate the FATT review of standalone ML-KEM in TLS. A few WG participants have already volunteered to do formal analysis in ProVerif. This draft also offers some preliminary discussion to help the developers and policy makers make informed choices. Finally, the draft also aims to reduce the endless repitition of arguments from both sides presented on several lists by documenting these arguments so they can simply be referred to. 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 consistent with process, symbolic and computational analysis (to be interpreted as in SoK) of standalone ML-KEM in the context of TLS is helpful here. We believe that if the author or any WG participant has done any formal analysis, it would be very helpful to present the current state of formal analysis in the next meeting for discussion. Some existing computational analysis for standalone ML-KEM in TLS include this and this. Both are based on pen-and-paper proofs.

Motivation requires to document the risks in the security considerations. To support those requirements for , this draft aims to formally study the security of standalone ML-KEM in TLS 1.3. This is because of the following reasons. In the last WGLC, had an opposition of several (ca. 25 in our understanding) WG participants -- even more than the supporters (ca. 21 in our understanding). We see 2 possible options:

• Continue tabletop discussions on subjective estimation of risks, costs, tradeoffs, etc., and keep burning WG energy by endless repitition.
• Do some technical analysis using (symbolic and computational) formal methods to get a confirmation on the security of standalone ML-KEM in the context of TLS and offer a statement for security considerations.

We believe the former cannot resolve the dispute. We sincerely hope the latter will help.

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. Adversary can record all traffic and decrypt it when ML-KEM is broken. The opinions here vary from "ML-KEM is probably secure" to "ML-KEM is probably already secrectly broken." Formal methods can operate under the assumption that ML-KEM is secure, and focus on the integration of ML-KEM in TLS under this assumption.

• As an example, formal methods can help justify design choices, such as the preference for hybrids. 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 shared secret to the TLS transcript hash.

Previous Formal Requests for FATT Review We have formally requested the chairs to initiate the FATT process for . See this and this.

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 We attest that: 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 existing proofs in ProVerif, therefore, utilize this symmetry for the commutativity of the key shares g^x and g^y, where g^x and g^y represent the public key shares of the endpoints. In ProVerif syntax: (see original source here and re-used 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 key shares g^x and g^y in a traditional key exchange, a KEM creates a roles-asymmetry where only one of the endpoints (client in above example) sends the public encapsulation key ek and the peer (server) sends a ciphertext ct. This asymmetry breaks the existing proofs of TLS 1.3 in ProVerif and requires a new proof. Please note that breaking the existing ProVerif proof does not necessarily mean that the ML-KEM proposal in TLS is insecure. It just means that a new proof is required. We welcome feedback from the community on how to fix the ProVerif proofs while preserving the cryptographic soundness.

Justification based on FATT Process Our formal request for FATT review is fully in conformance with the current process, which explicitly states: As presented in , we attest that modifies the:

• TLS key schedule
• cryptographic protocol such that commutativity property is no longer valid.

This breaks the following proofs in ProVerif:

• Bhargavan et al.'s model of draft 20 of TLS 1.3: and and all 5 public forks as well as one nested fork:
  • arthuraa/reftls
  • blipp/reftls
  • chris-wood/reftls
  • ekr/reftls
    • ajayeeralla/reftls
  • jhoyla/reftls
• Our previous work extending the model of Bhargavan et al. to the current state of and integrating remote attestation: and (under Apache-2.0 License) and all 3 public forks:
  • jupenur/formal-spec-id-crisis
  • nathanaelritz/formal-spec-id-crisis
  • telephonicrobotics/formal-id-crisis-spec
• A couple of our ongoing works which are not yet public

Hybrid ML-KEM? Some participants have raised concern that the same issue may apply to hybrid ML-KEM as well. Technically, a proof of is done in the computational model using CryptoVerif (cf. ref). As per list discussion, it appears that the proof applies to the latest version of the spec , as there are no substantive changes from the perspective of formal proof. Moreover, we believe that the two drafts are incomparable on this specific point as hybrid ML-KEM still has some level of symmetry. From formal (symbolic) analysis perspective, g^x and g^y are still sent in hybrid ML-KEM, g^xy is still computed and we believe the commutativity property is applicable for that part as-is. From formal (symbolic) analysis perspective, ML-KEM is complementary to that. Specifically, from , for the symbolic analysis, X25519MLKEM768 may be viewed as:

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:

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 at least 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.

Issues That Formal Methods Probably Cannot Solve The answers to the following issues are largely dependent on several factors, and the opinions vary largely. It is necessary to mention that even several respectable cryptographers in the community are not aligned on the issue -- for example see the long bet. Hence, our personal opinion is probably not that important. Probably the best we can do is to capture our understanding of the views of WG participants.

Thorough Review Please see a very thorough review here, which is self-sufficient.

'Significantly Harder' Argument Some participants believe in the 'significantly harder' argument, which assumes independence of breakage of ML-KEM and traditionals: Given the very different type of cryptographic constructions involved, we believe independence might be a reasonable assumption. Please see this for what "broken" may mean here modulo some exclusions. Some participants disagree with 'significantly harder' argument, but in our understanding, the counter-arguments seem to break the exclusions. Please note that this argument is based on the security of primitives, rather than the composition of primitives in protocols. Hence, formal methods probably have nothing to help here.

Urgency It is unclear whether and if applicable when Cryptographically-Relevant Quantum Computer (CRQC) will eventually become practical. The opinions vary from never because of complicated physics (see this) to be prepared for it as early as 2029 (see Google 2029 and Cloudflare 2029). Technically, please note that Google has not even released the quantum circuit underlying their recent claims -- apparently the reason for this urgency. So Google's claims are not yet justified. Moreover, in our understanding, these deadlines are for PQ-based protection in general regardless of hybrid KEMs or standalone KEMs in TLS. Since hybrid KEMs already exist, these deadlines are mainly for quantum-safe authentication. In any case, some participants see no reason to create panic for publication of based on this because many implementations -- such as OpenSSL -- have already implemented standalone ML-KEM, and it is just a matter of enabling it. And frankly, nobody needs permission from the IETF to enable it.

"Cost" "Cost" has been presented on the list as the motivation for standalone ML-KEM in TLS but no supporting analysis has yet been presented. Our observation from is that -- for example -- for X25519MLKEM768, the traditional part seems negligible compared to ML-KEM part in key_exchange:

Field	ML-KEM part	X25519
Client share	1184	32
Server share	1088	32

We believe other "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.

Is Publication Necessary? Code Points for ML-KEM have already been assigned. provides detailed rationale as to why publication of such documents and the debates around that may be unnecessary. In our understanding, makes similar arguments.

Shiny New Crypto ML-KEM is quite new in the IETF and even in the IRTF. Some WG participants have shown concern over premature publication of until a detailed analysis has been done by CFRG. CFRG is starting some efforts for analysis. The extended deadline for submission is 22.06. Please see the latest CFRG chairs email for further details.

Formal Mapping of FIPS to IETF BCP14 As discussed on the TLS list, we are not aware of any formal mapping of the FIPS recommendations to the IETF BCP14 terminology, such as SHOULD vs. MUST. In general, we believe re-using FIPS recommendations is ambiguous for IETF readers.

Outstanding NIST Comments Some participants believe that NIST has rushed through the process and not addressed all the comments that were submitted during the open review. Please see comments here.

Too Early Some participants simply believe that publication of and related discussions are just too early and unnecessary.

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 National Institute of Standards and Technology (U.S.) 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. 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. IETF TLS WG 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. 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 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 IEEE Aiven This document describes the current practices for handling new cryptography within the IETF. Some of these practices are informal and depend on individuals in certain relevant roles, such as Working Group Chairs, the Security Area Directors and the Independent Stream Editor. This document is intended to increase consistency and transparency in how the IETF handles new cryptography, such as new algorithms, ciphers and new primitives or combiners, by providing a reference for the cryptographic practices within the IETF. This document does not describe any new policies and does not prohibit exceptions in the described current practices. Cisco People keep pitching drafts to the TLS Working Group where the only thing the draft does is register a code point for a cryptographic algorithm. Stop doing that. It's unnecessary. Write an email to IANA instead. All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. PQShield AWS Cloudflare University of Waterloo This draft defines three hybrid key agreement mechanisms for TLS 1.3 - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 - that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie- Hellman) exchange. University of Waterloo Cisco Systems University of Haifa Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. University of Waterloo Cisco Systems University of Haifa and Meta Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3.

Acknowledgments We would like to thank Yaakov Stein, Ilari Liusvaara, John Preuß Mattsson, Eric Rescorla, Brian E Carpenter, and Nadim Kobeissi for their valuable feedback and contributions. is largely based on the opinions of many IETF participants. Text in is based on the proposal by John Preuß Mattsson. 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

-01

• Added justification based on FATT process:
• Reorganization, specially in motivation
• Added some common arguments:
• Comparison with hybrid ML-KEM