]> TU Dresden, Germany

muhammad_usama.sardar@tu-dresden.de

Independent Submission Stream This memo is a work-in-progress and maps out the technical facets relevant to the quantum-resistant key establishment in TLS 1.3 and provides some preliminary discussion to help developers and policymakers make informed choices. In particular, it presents hybrid key establishment and standalone ML-KEM in TLS 1.3. Moreover, it offers minimal implementation guidance for hybrid key establishment. The memo finally presents technical insights into hybrid key establishment and standalone ML-KEM in TLS 1.3. Our observation is that hybrid key establishment is preferable over standalone ML-KEM until a powerful CRQC exists which breaks most bits of pre-quantum. This memo is not a standard nor has it been shown to have consensus of the IETF community. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Readers are assumed to be familiar with , , and . Please note that the memo has currently several hyperlinks.

Objectives The memo serves three objectives:

• Identifying the underlying technical facets and common complexities of the deployment to provide clarity
• Minimal implementation guidance for hybrid key establishment
• Summary of formal methods works for hybrid key establishment and standalone ML-KEM in an accessible and intuitive way

Identifying Different Technical Facets The memo identifies technical facets that affect deployment reasoning. Facets are categorized as primitive-level and protocol-level. The focus of the latter is on the integration in TLS. Examples include break timing, residual pre-quantum security, deployment cost, patents, and implementation behavior.

Minimal Implementation Guidance for Hybrid Key Establishment The minimal implementation consideration for hybrid key establishment is not only whether ML-KEM is secure as a primitive, but also whether a TLS deployment can show that both hybrid components were validated, transcript-bound, and fail-closed under the negotiated group.

Technical Insights The memo covers the formal methods for hybrid key establishment and standalone ML-KEM in TLS. Formal methods mostly operate at the protocol-level. Formal methods can provide additional value in order to maintain the high cryptographic assurance of TLS. This includes symbolic and computational analysis (to be interpreted as in SoK) of integration of standalone ML-KEM in the context of TLS. Specifically, it covers the formal analysis in ProVerif on the potential issue of asymmetry. The analysis confirms that asymmetry is not a problem. Formal analysis can address some protocol-composition questions, but it does not settle every deployment or policy question relevant to standalone ML-KEM and hybrid key establishment.

Motivation An adversary can record all traffic and decrypt it later when ML-KEM is broken. The opinions of the community on this matter vary from "ML-KEM is secure" to "ML-KEM is probably already secretly 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 hybrid key establishments. It can also help identify all the assumptions under which the properties hold.
• Computational analysis -- using tools such as CryptoVerif -- seems like a reasonable approach to ensure security of ML-KEM in TLS, such as binding shared secret ss to the TLS transcript hash.

Intuition Leaking out the ECDHE key from hybrid key establishment should downgrade the security to the level of a standalone ML-KEM. Therefore, hybrid key establishment is in general more secure, unless:

• ECDHE is fully broken, in which case it still falls equivalent to standalone ML-KEM,
• in the hypothetical scenario that there is an implementation bug in the ECDHE part which is triggered only in composition. We are not aware of any concrete evidence of such a scenario.

We believe that in general:

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
• Standalone ML-KEM refers to .
• Hybrid key establishment refers to and .

We believe that symbolic and computational models are complementary and not a substitute of each other.

Key Establishment and Key Encapsulation In traditional key exchange (DHKE), both endpoints send their public key shares g^x and g^y to derive a shared secret g^xy. In key encapsulation, 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. In a KEM, only one of the endpoints (client in above example) sends the public encapsulation key ek and the peer (server) sends a ciphertext ct.

Technical Facets The list of technical facets is not exhaustive and does not try to prioritize one facet over another. If an important facet is missing, the most useful contribution is a precise and concise PR with proposed text and references.

Primitive-level

Which breaks first: ML-KEM-768 or X25519? A core uncertainty for any hybrid and standalone comparison is: All three variables may remain uncertain for a long period of time. This makes it difficult to reduce the question to one simple ordering of "secure" and "insecure" choices.

Does CRQC Break All Bits of Pre-quantum? The impact of a CRQC on pre-quantum cryptography may not be uniform across all algorithms, security levels, and attack models. One concrete position is that a CRQC may break only a few bits rather than all effective pre-quantum security. This matters because a hybrid construction depends on the residual value of the traditional component after a quantum advance.

Two Hardness Problems Given the very different type of cryptographic constructions involved, one may assume independence between a break of ML-KEM and a break of the traditional key-exchange component (say X25519): Please see this for what "broken" may mean here modulo some exclusions. However, a reasonable position is that, in reality, cryptography is much more complicated than that and depending on the algorithms and the composition method, the probability can clearly be smaller than pq.

Confidence in ML-KEM ML-KEM is quite new in the IETF and even in the IRTF. CFRG is starting some efforts for detailed analysis. The extended deadline for submission is 22 June 2026. Please see the latest CFRG chairs email for further details. The confidence question is not only about calendar age. For deployers, the relevant technical question is how much assurance has accumulated for the structured-lattice setting, the parameter choices, the reduction assumptions, and the implementation behavior of the construction. That is a risk-management input.

Potentially Outstanding NIST Comments One concrete position is that not all comments submitted during the open review were fully addressed. Please see comments here.

Patents Some concerns related to patents on ML-KEM have been raised. See some relevant patents here.

Protocol-level

Policy/Regulations Some countries have a regulatory requirement for hybrid key establishment. This is a deployment and compliance constraint, which overrides all technical questions.

Urgency It is unclear whether and if applicable when Cryptographically-Relevant Quantum Computer (CRQC) will eventually become practical. Public assessments range from skepticism based on the difficulty of the physics (see this) to migration targets that aim to be prepared as early as 2029 (see Google 2029 and Cloudflare 2029). The technical details behind some public timeline claims are not yet fully public. In particular, Google has not even released the quantum circuit underlying their recent claims -- apparently the reason for this urgency. These claims are therefore best treated as deployment-planning inputs rather than as proof of a specific CRQC arrival date. Moreover, in our understanding, these deadlines are for PQ-based protection in general. Since hybrid key establishment is widely in use, these deadlines are mainly for quantum-safe authentication. A separate deployment point is that publication timing does not by itself control deployment timing. Implementations, such as OpenSSL, already include standalone ML-KEM support, and deployments can enable available code according to their own policy and risk assessment.

Recommendation of Designers The authors of Kyber/ML-KEM (see ref) say:

Cost Cost may be the motivation for standalone ML-KEM in TLS but we are not aware of any supporting analysis. Our observation from is that -- for example -- for X25519MLKEM768, the traditional part seems negligible compared to ML-KEM part in key_exchange:

Bytes in field	PQ part (ML-KEM)	Traditional part (X25519)
Client share	1184	32
Server share	1088	32

This observation does not by itself settle wire-size or middlebox questions. Those questions need to be measured at the full TLS handshake level, including ClientHello size, record boundaries, fragmentation behavior, retry paths, and the deployment's existing extension set. Other costs depend on several factors -- including implementation details, deployment scenario, latency budget, memory pressure, code complexity, and operational rollout cost -- and should not be treated as one scalar value. For broad Internet-facing deployments, ECDHE and hybrid key establishment support are likely to remain necessary for compatibility and policy reasons, so standalone ML-KEM does not automatically remove the implementation, testing, or operational cost of the traditional component. The conclusion may be different for closed, constrained, or endpoint-controlled deployments, but that is a deployment-class-specific claim and needs analysis of those environments. There seems to be a need for a thorough study to understand the cost. A useful analysis would separate wire bytes, CPU, memory, latency, implementation complexity, and operational rollout cost.

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.

Formal Mapping of FIPS to IETF BCP14 As discussed on the TLS mailing-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, re-using FIPS recommendations may be ambiguous for IETF readers and implementers.

Implementation Bugs Implementation bugs are a separate risk from primitive-level cryptanalysis. Hybrid key establishment may mitigate some single-component failures, but only if the implementation actually validates both components, binds them to the same transcript, derives traffic secrets only after both components are accepted, and fails closed when either component fails.

Depth of Hybrids The depth of a hybrid is itself a design question. ML-KEM plus ECC is only one composition point; other designs could combine module lattices, code-based KEMs, or hash-based components. If the motivation for standalone ML-KEM is size, constrained deployment, or operational simplicity, another technical question is whether a different hybrid design in the space could address that motivation while retaining a second cryptographic component.

Implementation-Facing Negative Cases A short set of negative cases can help implementers check that the intended hybrid binding property is reflected in their APIs, transcript handling, and key schedule integration. In particular, implementations of hybrid key establishment ought to reject, or fail safely on, cases such as the following:

• Malformed or missing shares: The negotiated group is a hybrid group, but one component of the peer key share is missing, malformed, or associated with a different group.
• Mixed transcript context: The ECDHE and KEM values are individually well-formed, but assembled from different handshakes, transcript contexts, or negotiated groups.
• Fallback after hybrid negotiation: A peer attempts to continue the handshake as standalone ECDHE or standalone ML-KEM after a hybrid group was negotiated.
• Premature secret derivation: Application traffic secrets are derived before both hybrid components have been validated and accepted under the negotiated group.
• API/logging ambiguity: Exported state, logs, traces, or implementation APIs make a hybrid exchange appear as if only one component was used or accepted.

They are implementation-facing checks that help bridge the "both components are bound and accepted" property to concrete failure modes that implementations can accidentally mishandle.

Argument Matrix for Implementation Review The discussion above can be read as an argument matrix for implementers and reviewers. The point is not to resolve every policy preference in this memo, but to make each recurring argument map to a concrete review question.

Argument	Implementation-facing review question	Why it matters
Hybrid key establishment retains two components.	Does the implementation make it clear that both the ECDHE and ML-KEM components were present, validated, and bound to the same negotiated group and transcript?	Otherwise a successful handshake may not actually reflect the "both components are bound and accepted" property.
Standalone ML-KEM has a single KEM shared secret.	Are failures in encapsulation, decapsulation, transcript binding, and key-schedule input handled as fail-closed errors rather than as retry or fallback paths?	A standalone construction has no second key-exchange component to preserve confidentiality if the ML-KEM path is mishandled.
Hybrid fallback is useful only when it is explicit.	After a hybrid group is negotiated, can either endpoint silently continue as standalone ECDHE or standalone ML-KEM?	Silent continuation changes the negotiated security property and makes interop failures hard to distinguish from downgrades.
Cost claims are deployment-dependent.	Are claimed savings measured separately for wire bytes, CPU, memory, latency, code complexity, and operational rollout?	Treating cost as a single value can hide whether a deployment is trading away cryptographic robustness for a negligible or unmeasured gain.
Formal models do not cover every implementation interface.	Do APIs, logs, exported state, and test harnesses expose enough detail to show which component failed or succeeded?	Reviewers need observable evidence that the implementation behavior matches the protocol-level claim.

This matrix is deliberately small. It is intended to help a reviewer decide whether a concrete implementation or deployment argument belongs in the formal-methods discussion, in implementation guidance, or in a separate operational cost analysis.

Technical Analysis

Minimum Viable Modeling Based on the discussion on TLS mailing-list, simply replacing ideal DHKE by ideal ML-KEM in the formal model is not very useful. We ought to focus on the more security-critical questions about integration of ML-KEM in TLS. We present a few high-level observations to consider for technical analysis:

• The model ought to consider that any agent could have initiated the TLS, rather than assigning the agents with static roles of client and server in the model. When agents are assigned non-static roles, it would be interesting to see whether the asymmetry issue becomes visible in some property.
• Different failure modes can be modeled.
• A large part of the problem is the careful investigation of what to model, at which abstraction level, under what threat model, under what system model, under what implementation scenarios etc.
• It will be interesting to see some analysis about any subtle cases where hybrid key establishment in TLS is not at least as good as standalone ML-KEM in TLS, since hybrid key establishment is the de facto industry standard.
• We believe brainstorming about some robustness (vs. security) properties would also be useful. Even if the security properties hold, does standalone ML-KEM make side-channel leakage easier? This might be a valuable consideration for the implementers.
• Analysis may be helpful to ensure that the changes -- such as the removal of hash function (cf. Appendix C.1, bullet 3 in ) -- from Kyber to ML-KEM preserve the security proofs of Kyber.

Any analysis on these or related security and robustness matters is very welcome as a PR.

Symbolic Analysis For implementers, the symbolic view can be read as a component-failure exercise. Instead of asking how hard ML-KEM or ECDHE is to break, the analysis may ask whether security properties still hold under Dolev-Yao attacker if one component secret is already available to the adversary. For brevity, we omit other assumptions in the properties below and focus on the difference. This assumes the hybrid construction to be secure.

Hybrid Key Establishment Hybrid key establishment still maintains the DHKE part. From formal (symbolic) analysis perspective, g^x and g^y are still sent in hybrid key establishment, g^xy is still computed. From formal (symbolic) analysis perspective, ML-KEM is complementary to that. Specifically, from , for the symbolic analysis, X25519MLKEM768 in TLS may be viewed as: Formally, the property hybrid key establishment should provide is: In short, hybrid key establishment preserves ECDHE component gxy, and concatenates ML-KEM component ss as an additional factor. So as long as at least one of these two secrets is not available to the adversary, all security properties should hold. In particular, even if ML-KEM is completely broken, i.e., ss is available to the adversary, the protocol retains the security level of ECDHE.

Standalone ML-KEM At the symbolic level, some analysis -- such as this for KEMTLS in Tamarin -- exists. In our understanding, both client and server encapsulate, which may bring the symmetry. The formal property standalone ML-KEM provides is:

Results The symbolic analysis was done in ProVerif by Nadim Kobeissi, who concludes: Under the stated model assumptions, the results confirm that integrating a KEM into TLS is secure as long as the primitive itself is secure. In our understanding, the results also imply a clear preference for hybrids under the Dolev-Yao model: if the shared secret from ML-KEM becomes available to the adversary (for example, due to an implementation bug), standalone ML-KEM loses both confidentiality and the server authentication property. This should not be read as saying that the signature algorithm or CertificateVerify mechanism is itself broken. Rather, once the only key-establishment secret is available to the adversary, the Finished-key agreement property captured by the model no longer holds. Under the same condition, hybrid key establishment still preserves these modeled properties as long as the (EC)DHE secret is not available to the adversary. We believe this applies until a powerful CRQC exists which breaks most of the bits of pre-quantum, where the condition of (EC)DHE being available to the adversary is violated. A practical reading of the result from implementer's and policymaker's perspective is:

• Standalone ML-KEM has no second key-establishment component if ss is exposed or mishandled.
• Hybrid key establishment retains a surviving ECDHE component if ss is exposed but gxy remains secret.
• Implementation tests should therefore verify not only that the handshake succeeds, but that both hybrid components were present, validated, transcript-bound, and fail-closed before traffic secrets are derived.

The artifacts are available here for independent review.

Computational Analysis

Hybrids Technically, a proof of is done in the computational model using CryptoVerif (cf. ref). As per discussion on TLS mailing-list, it appears that the proof applies to the latest version of the spec , as there seem to be no substantive changes from the perspective of formal proof.

Standalone ML-KEM Some existing computational analysis for standalone ML-KEM in TLS include this, this, and this. All of these are based on pen-and-paper (computational) proofs. For implementers, the practical reading of these analyses is a key-schedule and transcript-binding check. The question is whether the KEM shared secret is introduced into TLS in a way that preserves the claimed security property. This should not be read as a replacement for malformed-input, API-misuse, or fallback testing. For ML-KEM in particular, invalid ciphertext processing uses implicit rejection rather than a conventional decapsulation-failure signal; the TLS-level behavior to test is that inconsistent KEM inputs, wrong group selection, transcript mismatch, or incomplete fallback paths do not produce a usable handshake and do not silently continue under a different negotiated security property.

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. Technically, formal proof only guarantees anything if all the assumptions hold, which is unlikely in practice. Hence, formal methods should be used as complementary to increase confidence and not as substitute of other analysis methods. For implementations, this means that formal-methods results should be paired with negative testing and review evidence for malformed shares, transcript mismatches, silent fallback, premature secret derivation, and failure handling.

IANA Considerations This memo 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. 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 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. Symbolic Software

Contributors Nadim Kobeissi performed a thorough formal analysis at high priority based on our call for analysis in previous versions of the memo to get a confirmation. Text in was proposed by Songbo Bu and largely used as-is. He also proposed revisions in and , in particular implementer's perspective. Text in is based on the proposal by John Preuß Mattsson. is based on mailing-list discussion, referenced technical facets, and deployment questions raised during review. We gratefully thank Yaakov Stein and Ilari Liusvaara for their substantial technical guidance, valuable feedback, and contributions.

Acknowledgments We thank Eric Rescorla, Brian E. Carpenter, Tibor Jager, and Eliot Lear for their valuable feedback. We acknowledge several IETF participants who have contributed to this memo with their insights. 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 key establishment

-02

• Added gap analysis
• What to model and analyze?
• Added FATT review is harmless
• Extended comparison with hybrid key establishment
• Opinion of designers

-03

• Completely restructured and reframed after confirmation by formal analysis
• Added implementation-facing negative cases and argument matrix
• Some new arguments: implementation bugs, depth of hybrids, policy, all bits, which primitive breaks first?

-04

• Remove links to opinion of IETF participants
• Inform the reader of the technical facets
• Implementer's perspective