Post-Quantum Hybrid ML-KEM-1024/X448 Key Agreement for TLS 1.3

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 12 April 2027.¶

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.¶

Table of Contents

1. Introduction

The transition to post-quantum cryptography requires new key exchange mechanisms for TLS 1.3 [RFC9846]. Post-Quantum/Traditional (PQ/T) hybrid key exchange combines a post-quantum key exchange algorithm such as ML-KEM [FIPS203] with a traditional key exchange algorithm such as X448 [RFC7748], allowing deployments to gain protection against future Cryptanalytically Relevant Quantum Computers (CRQC) while retaining the security of previously trusted traditional key exchange algorithms.¶

[RFC9954] specifies a general design for hybrid key exchange in TLS 1.3. [RFC10024], [I-D.rosomakho-tls-ecdhe-mlkem512], and [I-D.yang-tls-hybrid-sm2-mlkem] apply this design to define PQ/T hybrid key exchange algorithms based on ML-KEM. [I-D.ietf-tls-mlkem] defines standalone TLS 1.3 key exchange algorithms based on ML-KEM.¶

This document applies the hybrid key exchange design specified in [RFC9954] to define MLKEM1024X448, a PQ/T hybrid key exchange algorithm for TLS 1.3 that combines ML-KEM-1024 with X448. The algorithm provides a hybrid key exchange option targeting security category 5 [SP800-57], matching the security level of AES-256 and ChaCha20 and providing a higher security level than X25519MLKEM768 [RFC10024]. A large security margin can protect against future cryptanalytic advances, misuse, and implementation errors. Compared with P-curves offering a similar security level, X448 is significantly faster and provides greater implementation robustness. A FIPS-validated implementation of MLKEM1024X448 ensures that the ML-KEM-1024 component is FIPS-validated. This is not necessarily the case for SecP384r1MLKEM1024 [RFC10024], where only the secp384r1 component might be FIPS-validated while the ML-KEM-1024 component is not.¶

The algorithm defined in this document is intended for use with TLS 1.3 [RFC9846], DTLS 1.3 [RFC9147], and QUIC [RFC9001] and follows the hybrid key exchange construction defined in [RFC9954]. It defines only an additional TLS NamedGroup value and its associated key share and shared secret encodings. It does not modify the TLS 1.3 handshake, key schedule, or negotiation mechanisms.¶

2. Terminology

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.¶

This document uses the terminology of TLS 1.3 [RFC9846], hybrid key exchange in TLS 1.3 [RFC9954], and ML-KEM [FIPS203].¶

3. The MLKEM1024X448 Key Exchange Algorithm

This document defines the TLS NamedGroup MLKEM1024X448 for use with the TLS 1.3 supported_groups and key_share extension. Key shares and shared secrets are encoded by concatenating the component values in the order indicated by the name. All encodings are fixed-length.¶

struct {
    opaque kem_key[1568];
    opaque ecdhe_key[56];
} MLKEM1024X448ClientShare;

struct {
    opaque kem_ciphertext[1568];
    opaque ecdhe_key[56];
} MLKEM1024X448ServerShare;

concatenated_shared_secret =
    MLKEM1024_shared_secret || X448_shared_secret

4. Security Considerations

MLKEM1024X448 uses the hybrid construction specified in [RFC9954]. Its security relies on the TLS 1.3 transcript binding and key schedule. The security considerations in [RFC9846], [FIPS203], [SP800-227], [RFC7748], [RFC9954], and [RFC10024] apply to the algorithm defined in this document. An MLKEM1024X448 key share, or any of its components, MUST NOT be reused for multiple connections, as required by TLS 1.3 [RFC9846].¶

ML-KEM-1024 provides the highest security among the ML-KEM parameter sets defined in [FIPS203], namely post-quantum security category 5 [SP800-57], matching the security level of AES-256 and ChaCha20. X448 provides approximately 224 bits of classical security [RFC7748] and no quantum resistance. Compared with P-curves offering a comparable security level, X448 is significantly faster and provides greater implementation robustness.¶

Compared with X25519MLKEM768 [RFC10024], which has the value Y in the Recommended column of the IANA TLS Supported Groups registry [IANA], MLKEM1024X448 provides a higher security level at the cost of moderately larger messages and higher computational cost. As with X25519MLKEM768, the key share sizes are dominated by the ML-KEM component and the computational cost is dominated by the ECDHE component. ML-KEM-1024, with its security category 5, provides a larger security margin than ML-KEM-768, which can protect against future advances in lattice cryptanalysis, as well as misuse and implementation errors.¶

A fundamental requirement of hybrid constructions is that their security is at least as high as that of their strongest component; that is, the construction preserves the cryptographic security properties of its components [EU25], [EU26], [NCSC26], [SP800-227]. The PQ/T hybrid key exchange algorithm defined in this document is designed to meet this requirement. In particular, it preserves the quantum-resistance and indistinguishability under adaptive chosen-ciphertext attack (IND-CCA2) security of ML-KEM [FIPS203].¶

Similar to X25519MLKEM768 [RFC10024] and MLKEM512X25519 [I-D.rosomakho-tls-ecdhe-mlkem512], a FIPS-validated implementation of MLKEM1024X448 guarantees that the ML-KEM component is FIPS-validated. This is not the case for SecP256r1MLKEM768 and SecP384r1MLKEM1024 [RFC10024], whose primary design goal was to enable vendors to sell existing FIPS-validated implementations of P-256 and P-384 as "quantum-resistant", even though only the quantum-vulnerable components are FIPS validated. FIPS-validated implementations of SecP256r1MLKEM768 and SecP384r1MLKEM1024 might already be disallowed by 2030 [EO14412]. Users seeking a FIPS-validated key exchange in TLS should use FIPS-validated ML-KEM.¶

Availability is a fundamental security property and part of the CIA triad in information security [SP800-12]. Large client key shares, such as the 1624-byte MLKEM1024X448 key share, are known to cause interoperability problems with non-compliant or buggy legacy TLS implementations, as well as with middleboxes and other network infrastructure that impose non-compliant limitations on large TLS ClientHello messages. Large key shares also increase bandwidth, memory, and computational costs for constrained endpoints or deployments operating over lossy or bandwidth-constrained networks, potentially reducing availability.¶

Implementations MUST NOT use MLKEM1024X448 with TLS 1.2 or DTLS 1.2, which are obsolete and should be phased out as soon as possible. 3GPP already mandates that TLS 1.2 be disabled by default.¶

5. IANA Considerations

This document requests that IANA register one new entry in the TLS Supported Groups registry [IANA], according to the procedures in Section 6 of [RFC9847].¶

6. References

Acknowledgments

The authors thank the authors of previous drafts from which this draft borrowed text. The authors thank someone for their valuable comments and feedback on this draft.¶

Authors' Addresses