Transport Layer Security J. Preuß Mattsson Internet-Draft S. Ruohomaa Intended status: Informational Ericsson Expires: 12 April 2027 9 October 2026 Post-Quantum Hybrid ML-KEM-1024/X448 Key Agreement for TLS 1.3 draft-preussmattsson-tls-mlkem1024-x448-01 Abstract This document defines a post-quantum/traditional hybrid key exchange algorithm for TLS 1.3 that combines ML-KEM-1024 with X448: MLKEM1024X448. The algorithm provides a hybrid key exchange option targeting a higher security level than X25519MLKEM768, matching the security level of AES-256 and ChaCha20. 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. The algorithm defined in this document is intended for use with TLS 1.3, DTLS 1.3, and QUIC and follows the general hybrid key exchange construction defined 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. Preuß Mattsson & Ruohomaa Expires 12 April 2027 [Page 1] Internet-Draft ML-KEM-1024/X448 Hybrid October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The MLKEM1024X448 Key Exchange Algorithm . . . . . . . . . . 3 3.1. Client and Server Key Shares . . . . . . . . . . . . . . 3 3.2. Shared Secret . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.1. MLKEM1024X448 . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 Preuß Mattsson & Ruohomaa Expires 12 April 2027 [Page 2] Internet-Draft ML-KEM-1024/X448 Hybrid October 2026 [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. 3.1. Client and Server Key Shares For MLKEM1024X448, the client key_exchange value contains the ML- KEM-1024 encapsulation key followed by the X448 public key: struct { opaque kem_key[1568]; opaque ecdhe_key[56]; } MLKEM1024X448ClientShare; The server key_exchange value contains the ML-KEM-1024 ciphertext followed by the X448 public key: Preuß Mattsson & Ruohomaa Expires 12 April 2027 [Page 3] Internet-Draft ML-KEM-1024/X448 Hybrid October 2026 struct { opaque kem_ciphertext[1568]; opaque ecdhe_key[56]; } MLKEM1024X448ServerShare; Both client and server MUST check that the received key share is 1624 bytes and abort with an "illegal_parameter" alert if it fails. The server MUST perform the encapsulation key check described in Section 7.2 of [FIPS203] on the client's ML-KEM-1024 encapsulation key and abort with an "illegal_parameter" alert if it fails. If ML- KEM decapsulation fails for any reason, the client MUST abort with an "internal_error" alert. 3.2. Shared Secret For MLKEM1024X448, the 32-byte ML-KEM shared secret is produced by ML-KEM-1024 encapsulation and decapsulation as specified in [FIPS203], and the 56-byte X448 shared secret is produced as specified in Section 7.4.2 of [RFC9846] by the X448 Diffie-Hellman operation. The 88-byte asymmetric shared secret input to the TLS 1.3 key schedule Section 7.1 of [RFC9846] is the concatenation of the ML- KEM shared secret followed by the X448 shared secret: concatenated_shared_secret = MLKEM1024_shared_secret || X448_shared_secret Both client and server MUST calculate the X448 part of the shared secret as described in Section 7.4.2 of [RFC9846], including the all- zero shared secret check, and abort with an "illegal_parameter" alert if it fails. 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]. Preuß Mattsson & Ruohomaa Expires 12 April 2027 [Page 4] Internet-Draft ML-KEM-1024/X448 Hybrid October 2026 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. Preuß Mattsson & Ruohomaa Expires 12 April 2027 [Page 5] Internet-Draft ML-KEM-1024/X448 Hybrid October 2026 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]. 5.1. MLKEM1024X448 Value: TBD Description: MLKEM1024X448 DTLS-OK: Y Recommended: N Reference: This document Comment: PQ/T hybrid combining ML-KEM-1024 with X448 6. References 6.1. Normative References [FIPS203] "Module-lattice-based key-encapsulation mechanism standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.203, August 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Preuß Mattsson & Ruohomaa Expires 12 April 2027 [Page 6] Internet-Draft ML-KEM-1024/X448 Hybrid October 2026 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . [RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025, . [RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July 2026, . [RFC10024] Kwiatkowski, K., Kampanakis, P., Westerbaan, B. E., and D. Stebila, "Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3", RFC 10024, DOI 10.17487/RFC10024, August 2026, . [SP800-227] Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., Silberg, H., and N. Waller, "Recommendations for key- encapsulation mechanisms", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.sp.800-227, September 2025, . 6.2. Informative References [EO14412] "Securing the Nation Against Advanced Cryptographic Attacks", June 2026, . Preuß Mattsson & Ruohomaa Expires 12 April 2027 [Page 7] Internet-Draft ML-KEM-1024/X448 Hybrid October 2026 [EU25] "A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography", June 2025, . [EU26] "EU Roadmap on PQC – Frequently Asked Questions", April 2026, . [I-D.ietf-tls-mlkem] Connolly, D., "ML-KEM Post-Quantum Key Agreement for TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- mlkem-11, 16 September 2026, . [I-D.rosomakho-tls-ecdhe-mlkem512] Rosomakho, Y., "Post-quantum hybrid ECDHE-MLKEM512 Key Agreement for TLSv1.3", Work in Progress, Internet-Draft, draft-rosomakho-tls-ecdhe-mlkem512-01, 14 September 2026, . [I-D.yang-tls-hybrid-sm2-mlkem] Yang, P., Peng, C., Hu, J., and S. Sun, "Hybrid Post- quantum Key Exchange SM2-MLKEM for TLSv1.3", Work in Progress, Internet-Draft, draft-yang-tls-hybrid-sm2-mlkem- 03, 14 November 2025, . [IANA] "IANA TLS Supported Groups Registry", n.d., . [NCSC26] "Nationella rekommendationer för övergången till kvantsäker kryptografi", May 2026, . [SP800-12] Nieles, M., Dempsey, K., and V. Pillitteri, "An introduction to information security", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-12r1, June 2017, . Preuß Mattsson & Ruohomaa Expires 12 April 2027 [Page 8] Internet-Draft ML-KEM-1024/X448 Hybrid October 2026 [SP800-57] Barker, E. and W. Barker, "Recommendation for Key Management: Part 1 — General Initial Public Draft", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-57pt1r6.ipd, December 2025, . 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 John Preuß Mattsson Ericsson Sweden Email: john.mattsson@ericsson.com Sini Ruohomaa Ericsson Finland Email: sini.ruohomaa@ericsson.com Preuß Mattsson & Ruohomaa Expires 12 April 2027 [Page 9]