idnits 2.17.1 draft-preussmattsson-tls-mlkem1024-x448-01.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (9 October 2026) is 23 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1568' on line 146 -- Looks like a reference, but probably isn't: '56' on line 147 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security J. Preuß Mattsson 3 Internet-Draft S. Ruohomaa 4 Intended status: Informational Ericsson 5 Expires: 12 April 2027 9 October 2026 7 Post-Quantum Hybrid ML-KEM-1024/X448 Key Agreement for TLS 1.3 8 draft-preussmattsson-tls-mlkem1024-x448-01 10 Abstract 12 This document defines a post-quantum/traditional hybrid key exchange 13 algorithm for TLS 1.3 that combines ML-KEM-1024 with X448: 14 MLKEM1024X448. The algorithm provides a hybrid key exchange option 15 targeting a higher security level than X25519MLKEM768, matching the 16 security level of AES-256 and ChaCha20. A large security margin can 17 protect against future cryptanalytic advances, misuse, and 18 implementation errors. Compared with P-curves offering a similar 19 security level, X448 is significantly faster and provides greater 20 implementation robustness. A FIPS-validated implementation of 21 MLKEM1024X448 ensures that the ML-KEM-1024 component is FIPS- 22 validated. The algorithm defined in this document is intended for 23 use with TLS 1.3, DTLS 1.3, and QUIC and follows the general hybrid 24 key exchange construction defined for TLS 1.3. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 12 April 2027. 43 Copyright Notice 45 Copyright (c) 2026 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The MLKEM1024X448 Key Exchange Algorithm . . . . . . . . . . 3 62 3.1. Client and Server Key Shares . . . . . . . . . . . . . . 3 63 3.2. Shared Secret . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. MLKEM1024X448 . . . . . . . . . . . . . . . . . . . . . . 6 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 6.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 The transition to post-quantum cryptography requires new key exchange 76 mechanisms for TLS 1.3 [RFC9846]. Post-Quantum/Traditional (PQ/T) 77 hybrid key exchange combines a post-quantum key exchange algorithm 78 such as ML-KEM [FIPS203] with a traditional key exchange algorithm 79 such as X448 [RFC7748], allowing deployments to gain protection 80 against future Cryptanalytically Relevant Quantum Computers (CRQC) 81 while retaining the security of previously trusted traditional key 82 exchange algorithms. 84 [RFC9954] specifies a general design for hybrid key exchange in TLS 85 1.3. [RFC10024], [I-D.rosomakho-tls-ecdhe-mlkem512], and 86 [I-D.yang-tls-hybrid-sm2-mlkem] apply this design to define PQ/T 87 hybrid key exchange algorithms based on ML-KEM. [I-D.ietf-tls-mlkem] 88 defines standalone TLS 1.3 key exchange algorithms based on ML-KEM. 90 This document applies the hybrid key exchange design specified in 91 [RFC9954] to define MLKEM1024X448, a PQ/T hybrid key exchange 92 algorithm for TLS 1.3 that combines ML-KEM-1024 with X448. The 93 algorithm provides a hybrid key exchange option targeting security 94 category 5 [SP800-57], matching the security level of AES-256 and 95 ChaCha20 and providing a higher security level than X25519MLKEM768 97 [RFC10024]. A large security margin can protect against future 98 cryptanalytic advances, misuse, and implementation errors. Compared 99 with P-curves offering a similar security level, X448 is 100 significantly faster and provides greater implementation robustness. 101 A FIPS-validated implementation of MLKEM1024X448 ensures that the ML- 102 KEM-1024 component is FIPS-validated. This is not necessarily the 103 case for SecP384r1MLKEM1024 [RFC10024], where only the secp384r1 104 component might be FIPS-validated while the ML-KEM-1024 component is 105 not. 107 The algorithm defined in this document is intended for use with TLS 108 1.3 [RFC9846], DTLS 1.3 [RFC9147], and QUIC [RFC9001] and follows the 109 hybrid key exchange construction defined in [RFC9954]. It defines 110 only an additional TLS NamedGroup value and its associated key share 111 and shared secret encodings. It does not modify the TLS 1.3 112 handshake, key schedule, or negotiation mechanisms. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 This document uses the terminology of TLS 1.3 [RFC9846], hybrid key 123 exchange in TLS 1.3 [RFC9954], and ML-KEM [FIPS203]. 125 3. The MLKEM1024X448 Key Exchange Algorithm 127 This document defines the TLS NamedGroup MLKEM1024X448 for use with 128 the TLS 1.3 supported_groups and key_share extension. Key shares and 129 shared secrets are encoded by concatenating the component values in 130 the order indicated by the name. All encodings are fixed-length. 132 3.1. Client and Server Key Shares 134 For MLKEM1024X448, the client key_exchange value contains the ML- 135 KEM-1024 encapsulation key followed by the X448 public key: 137 struct { 138 opaque kem_key[1568]; 139 opaque ecdhe_key[56]; 140 } MLKEM1024X448ClientShare; 142 The server key_exchange value contains the ML-KEM-1024 ciphertext 143 followed by the X448 public key: 145 struct { 146 opaque kem_ciphertext[1568]; 147 opaque ecdhe_key[56]; 148 } MLKEM1024X448ServerShare; 150 Both client and server MUST check that the received key share is 1624 151 bytes and abort with an "illegal_parameter" alert if it fails. 153 The server MUST perform the encapsulation key check described in 154 Section 7.2 of [FIPS203] on the client's ML-KEM-1024 encapsulation 155 key and abort with an "illegal_parameter" alert if it fails. If ML- 156 KEM decapsulation fails for any reason, the client MUST abort with an 157 "internal_error" alert. 159 3.2. Shared Secret 161 For MLKEM1024X448, the 32-byte ML-KEM shared secret is produced by 162 ML-KEM-1024 encapsulation and decapsulation as specified in 163 [FIPS203], and the 56-byte X448 shared secret is produced as 164 specified in Section 7.4.2 of [RFC9846] by the X448 Diffie-Hellman 165 operation. The 88-byte asymmetric shared secret input to the TLS 1.3 166 key schedule Section 7.1 of [RFC9846] is the concatenation of the ML- 167 KEM shared secret followed by the X448 shared secret: 169 concatenated_shared_secret = 170 MLKEM1024_shared_secret || X448_shared_secret 172 Both client and server MUST calculate the X448 part of the shared 173 secret as described in Section 7.4.2 of [RFC9846], including the all- 174 zero shared secret check, and abort with an "illegal_parameter" alert 175 if it fails. 177 4. Security Considerations 179 MLKEM1024X448 uses the hybrid construction specified in [RFC9954]. 180 Its security relies on the TLS 1.3 transcript binding and key 181 schedule. The security considerations in [RFC9846], [FIPS203], 182 [SP800-227], [RFC7748], [RFC9954], and [RFC10024] apply to the 183 algorithm defined in this document. An MLKEM1024X448 key share, or 184 any of its components, MUST NOT be reused for multiple connections, 185 as required by TLS 1.3 [RFC9846]. 187 ML-KEM-1024 provides the highest security among the ML-KEM parameter 188 sets defined in [FIPS203], namely post-quantum security category 5 189 [SP800-57], matching the security level of AES-256 and ChaCha20. 190 X448 provides approximately 224 bits of classical security [RFC7748] 191 and no quantum resistance. Compared with P-curves offering a 192 comparable security level, X448 is significantly faster and provides 193 greater implementation robustness. 195 Compared with X25519MLKEM768 [RFC10024], which has the value Y in the 196 Recommended column of the IANA TLS Supported Groups registry [IANA], 197 MLKEM1024X448 provides a higher security level at the cost of 198 moderately larger messages and higher computational cost. As with 199 X25519MLKEM768, the key share sizes are dominated by the ML-KEM 200 component and the computational cost is dominated by the ECDHE 201 component. ML-KEM-1024, with its security category 5, provides a 202 larger security margin than ML-KEM-768, which can protect against 203 future advances in lattice cryptanalysis, as well as misuse and 204 implementation errors. 206 A fundamental requirement of hybrid constructions is that their 207 security is at least as high as that of their strongest component; 208 that is, the construction preserves the cryptographic security 209 properties of its components [EU25], [EU26], [NCSC26], [SP800-227]. 210 The PQ/T hybrid key exchange algorithm defined in this document is 211 designed to meet this requirement. In particular, it preserves the 212 quantum-resistance and indistinguishability under adaptive chosen- 213 ciphertext attack (IND-CCA2) security of ML-KEM [FIPS203]. 215 Similar to X25519MLKEM768 [RFC10024] and MLKEM512X25519 216 [I-D.rosomakho-tls-ecdhe-mlkem512], a FIPS-validated implementation 217 of MLKEM1024X448 guarantees that the ML-KEM component is FIPS- 218 validated. This is not the case for SecP256r1MLKEM768 and 219 SecP384r1MLKEM1024 [RFC10024], whose primary design goal was to 220 enable vendors to sell existing FIPS-validated implementations of 221 P-256 and P-384 as "quantum-resistant", even though only the quantum- 222 vulnerable components are FIPS validated. FIPS-validated 223 implementations of SecP256r1MLKEM768 and SecP384r1MLKEM1024 might 224 already be disallowed by 2030 [EO14412]. Users seeking a FIPS- 225 validated key exchange in TLS should use FIPS-validated ML-KEM. 227 Availability is a fundamental security property and part of the CIA 228 triad in information security [SP800-12]. Large client key shares, 229 such as the 1624-byte MLKEM1024X448 key share, are known to cause 230 interoperability problems with non-compliant or buggy legacy TLS 231 implementations, as well as with middleboxes and other network 232 infrastructure that impose non-compliant limitations on large TLS 233 ClientHello messages. Large key shares also increase bandwidth, 234 memory, and computational costs for constrained endpoints or 235 deployments operating over lossy or bandwidth-constrained networks, 236 potentially reducing availability. 238 Implementations MUST NOT use MLKEM1024X448 with TLS 1.2 or DTLS 1.2, 239 which are obsolete and should be phased out as soon as possible. 3GPP 240 already mandates that TLS 1.2 be disabled by default. 242 5. IANA Considerations 244 This document requests that IANA register one new entry in the TLS 245 Supported Groups registry [IANA], according to the procedures in 246 Section 6 of [RFC9847]. 248 5.1. MLKEM1024X448 250 Value: TBD 252 Description: MLKEM1024X448 254 DTLS-OK: Y 256 Recommended: N 258 Reference: This document 260 Comment: PQ/T hybrid combining ML-KEM-1024 with X448 262 6. References 264 6.1. Normative References 266 [FIPS203] "Module-lattice-based key-encapsulation mechanism 267 standard", National Institute of Standards and Technology 268 (U.S.), DOI 10.6028/nist.fips.203, August 2024, 269 . 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 277 for Security", RFC 7748, DOI 10.17487/RFC7748, January 278 2016, . 280 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 281 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 282 May 2017, . 284 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 285 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 286 . 288 [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 289 Datagram Transport Layer Security (DTLS) Protocol Version 290 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, 291 . 293 [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol 294 Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, 295 . 297 [RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 298 and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025, 299 . 301 [RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key 302 Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July 303 2026, . 305 [RFC10024] Kwiatkowski, K., Kampanakis, P., Westerbaan, B. E., and D. 306 Stebila, "Post-Quantum Traditional (PQ/T) Hybrid Key 307 Agreement Mechanisms for TLS 1.3", RFC 10024, 308 DOI 10.17487/RFC10024, August 2026, 309 . 311 [SP800-227] 312 Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., 313 Silberg, H., and N. Waller, "Recommendations for key- 314 encapsulation mechanisms", National Institute of Standards 315 and Technology (U.S.), DOI 10.6028/nist.sp.800-227, 316 September 2025, . 318 6.2. Informative References 320 [EO14412] "Securing the Nation Against Advanced Cryptographic 321 Attacks", June 2026, . 325 [EU25] "A Coordinated Implementation Roadmap for the Transition 326 to Post-Quantum Cryptography", June 2025, 327 . 330 [EU26] "EU Roadmap on PQC – Frequently Asked Questions", April 331 2026, . 334 [I-D.ietf-tls-mlkem] 335 Connolly, D., "ML-KEM Post-Quantum Key Agreement for TLS 336 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 337 mlkem-11, 16 September 2026, 338 . 341 [I-D.rosomakho-tls-ecdhe-mlkem512] 342 Rosomakho, Y., "Post-quantum hybrid ECDHE-MLKEM512 Key 343 Agreement for TLSv1.3", Work in Progress, Internet-Draft, 344 draft-rosomakho-tls-ecdhe-mlkem512-01, 14 September 2026, 345 . 348 [I-D.yang-tls-hybrid-sm2-mlkem] 349 Yang, P., Peng, C., Hu, J., and S. Sun, "Hybrid Post- 350 quantum Key Exchange SM2-MLKEM for TLSv1.3", Work in 351 Progress, Internet-Draft, draft-yang-tls-hybrid-sm2-mlkem- 352 03, 14 November 2025, 353 . 356 [IANA] "IANA TLS Supported Groups Registry", n.d., 357 . 360 [NCSC26] "Nationella rekommendationer för övergången till 361 kvantsäker kryptografi", May 2026, 362 . 366 [SP800-12] Nieles, M., Dempsey, K., and V. Pillitteri, "An 367 introduction to information security", National Institute 368 of Standards and Technology, DOI 10.6028/nist.sp.800-12r1, 369 June 2017, . 371 [SP800-57] Barker, E. and W. Barker, "Recommendation for Key 372 Management: Part 1 — General Initial Public Draft", 373 National Institute of Standards and Technology, 374 DOI 10.6028/nist.sp.800-57pt1r6.ipd, December 2025, 375 . 377 Acknowledgments 379 The authors thank the authors of previous drafts from which this 380 draft borrowed text. The authors thank someone for their valuable 381 comments and feedback on this draft. 383 Authors' Addresses 385 John Preuß Mattsson 386 Ericsson 387 Sweden 388 Email: john.mattsson@ericsson.com 390 Sini Ruohomaa 391 Ericsson 392 Finland 393 Email: sini.ruohomaa@ericsson.com