RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3

Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10024.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

ML-KEM is a key encapsulation mechanism (KEM) defined in [NIST-FIPS-203]. It is designed to withstand cryptanalytic attacks from quantum computers.¶

[RFC9954] defines a framework for combining traditional key exchanges with next-generation key exchange in TLS 1.3. The goal of this approach is to provide security against both classical and quantum adversaries while maintaining compatibility with existing infrastructure and protocols.¶

This document applies the framework in [RFC9954] to ML-KEM and specifies code points for the hybrid groups.¶

2. Motivation

This document introduces three new supported groups for Post-Quantum Traditional (PQ/T) hybrid key agreements [RFC9794] in TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine ML-KEM with Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) in the manner described in [RFC9954]. Any of the hybrid groups specified in this document may be implemented in a FIPS-approved way as discussed in Section 5.¶

• The first group uses X25519 [RFC7748], is widely deployed, and often serves as the most practical choice for a single PQ/T hybrid combiner [RFC9794] in TLS 1.3.¶

• The second group uses secp256r1 (NIST P-256) [NIST-FIPS-186]. This group supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms.¶

• The third group uses secp384r1 (NIST P-384) [NIST-FIPS-186]. This group is intended for high-security environments that require FIPS-approved mechanisms with an increased security margin.¶

Key establishment using NIST curves is outlined in Section 6.1.2.2 of [NIST-SP-800-56A].¶

3. Terminology

[RFC9954] defines "traditional" algorithms as those that are already widely adopted and "next-generation" algorithms as those that are not yet widely adopted, such as post-quantum algorithms. In this document, ECDHE using Curve25519, P-256, or P-384 is considered traditional, while ML-KEM is considered next-generation.¶

[RFC9954] also defines a "hybrid" key exchange as the simultaneous use of multiple key exchange algorithms, with their outputs combined to provide security as long as at least one of the component algorithms remains secure, even if the others are compromised. This document uses the term "hybrid" with the same meaning.¶

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

4. Negotiated Groups

5. Regulatory Context

This section provides informal notes on how the hybrid key agreement mechanisms defined in this document relate to existing NIST guidance on key derivation and hybrid key establishment.¶

• FIPS-compliance. All groups defined in this document permit FIPS-approved key derivation as per [NIST-SP-800-56C] and [NIST-SP-800-135]. NIST Special Publication 800-56Cr2 [NIST-SP-800-56C] approves the usage of the HMAC-based Key Derivation Function (HKDF) [RFC5869] with two distinct shared secrets, with the condition that the first one is computed by a FIPS-approved key-establishment scheme. FIPS also requires a certified implementation of the scheme, which will remain more ubiquitous for secp256r1 in the coming years. For this reason, the ML-KEM shared secret is placed first in X25519MLKEM768, while the ECDHE shared secret is placed first in SecP256r1MLKEM768 and SecP384r1MLKEM1024. This means that for SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDHE implementation must be certified, whereas the ML-KEM implementation does not require certification. In contrast, for X25519MLKEM768, the ML-KEM implementation must be certified.¶

• SP800-227 compliance. NIST Special Publication 800-227 [NIST-SP-800-227] provides general guidance on the design and use of key encapsulation mechanisms, including hybrid constructions. The key agreements defined in this document follow the principles described in Section 4.6 of [NIST-SP-800-227], which discusses the combination of post-quantum and classical key-establishment schemes and the use of approved key combiners. In particular, the shared-secret concatenation and HKDF-based derivation used by TLS 1.3 are consistent with the composite-KEM constructions and key-combiner recommendations outlined in Sections 4.6.1 and 4.6.2 of [NIST-SP-800-227]. Section 4.6.3 of [NIST-SP-800-227] further provides relevant security considerations for hybrid KEM designs underlying the approach used in this document.¶

6. Security Considerations

The same security considerations as those described in [RFC9954] apply to the approach used by this document. The security analysis relies crucially on the TLS 1.3 message transcript, and one cannot assume a similar hybridization is secure in other protocols.¶

[NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers.¶

All groups defined in this document use and generate fixed-length public keys, ciphertexts, and shared secrets, which complies with the requirements described in Section 6 of [RFC9954].¶

During ML-KEM encapsulation, encapsulation randomness m is drawn from a random bit generator and encrypted (see [NIST-FIPS-203], Algorithms 17 and 20); the client, which holds the decapsulation key, then recovers m exactly during decapsulation (see [NIST-FIPS-203], Algorithm 18). Consequently, any information m carries about the generator's other outputs is also exposed to the client.¶

The disclosure of the output(s) of an insecure random number generator (RNG) when used in TLS can be used in an attack to compromise the state of the insecure RNG itself as described in [DUALECTLS]. The encapsulation randomness m in ML-KEM is an additional place where RNG output is disclosed to an active attacker. Implementers should follow the RBG guidance in [NIST-FIPS-203] and the random number generation guidance in Appendix C.1 of [RFC9846]. Implementers can choose to implement mechanisms from [RFC8937] for additional protection across sessions.¶

In contrast, the ECDH ephemeral scalars taken from the RNG are never directly disclosed to the peer. However, any passive observer with access to a cryptographically relevant quantum computer (CRQC) can recover the scalar, which is derived directly from RNG output. Regardless, ephemeral scalars should always be generated using a cryptographically secure RNG: for secp256r1 and secp384r1 as required by [NIST-SP-800-56A], and for X25519 as described in [RFC7748]; the guidance in Appendix C.1 of [RFC9846] applies here as well.¶

If the same insecure RNG is used by both algorithms, then a disclosure of state by one of the algorithms will also affect the security of the other algorithm.¶

7. IANA Considerations

Per this document, IANA has registered three new entries in the "TLS Supported Groups" registry, according to the procedures in Section 6 of [RFC9847]. These identifiers are to be used with the final version of ML-KEM ratified by NIST, which is specified in [NIST-FIPS-203].¶

8. References

Authors' Addresses