Post-Quantum Hybrid ML-KEM-1024/X448 Key Agreement for TLS 1.3
draft-preussmattsson-tls-mlkem1024-x448-01

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,
              <https://doi.org/10.6028/nist.fips.203>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

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, <https://www.rfc-editor.org/rfc/rfc7748>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9001>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc9147>.

   [RFC9846]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
              <https://www.rfc-editor.org/rfc/rfc9846>.

   [RFC9847]  Salowey, J. and S. Turner, "IANA Registry Updates for TLS
              and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025,
              <https://www.rfc-editor.org/rfc/rfc9847>.

   [RFC9954]  Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key
              Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July
              2026, <https://www.rfc-editor.org/rfc/rfc9954>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc10024>.

   [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, <https://doi.org/10.6028/nist.sp.800-227>.

6.2.  Informative References

   [EO14412]  "Securing the Nation Against Advanced Cryptographic
              Attacks", June 2026, <https://www.whitehouse.gov/
              presidential-actions/2026/06/securing-the-nation-against-
              advanced-cryptographic-attacks/>.

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,
              <https://ec.europa.eu/newsroom/dae/redirection/
              document/117507>.

   [EU26]     "EU Roadmap on PQC – Frequently Asked Questions", April
              2026, <https://ec.europa.eu/newsroom/dae/redirection/
              document/132120>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-tls-
              mlkem-11>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-rosomakho-
              tls-ecdhe-mlkem512-01>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-yang-tls-
              hybrid-sm2-mlkem-03>.

   [IANA]     "IANA TLS Supported Groups Registry", n.d.,
              <https://www.iana.org/assignments/tls-parameters/tls-
              parameters.xhtml#tls-parameters-8>.

   [NCSC26]   "Nationella rekommendationer för övergången till
              kvantsäker kryptografi", May 2026,
              <https://www.ncsc.se/siteassets/publikationer/nationella-
              rekommendationer-for-overgangen-till-kvantsaker-
              kryptografi-2026_tga.pdf>.

   [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, <https://doi.org/10.6028/nist.sp.800-12r1>.

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,
              <https://doi.org/10.6028/nist.sp.800-57pt1r6.ipd>.

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]