idnits 2.17.1 draft-ietf-tls-mlkem-11.txt: -(397): 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 2 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 (17 September 2026) is 46 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security D. Connolly 3 Internet-Draft Selkie Cryptography 4 Intended status: Informational 17 September 2026 5 Expires: 21 March 2027 7 ML-KEM Post-Quantum Key Agreement for TLS 1.3 8 draft-ietf-tls-mlkem-11 10 Abstract 12 This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as 13 NamedGroups and registers IANA values in the TLS Supported Groups 14 registry for use in TLS 1.3 to achieve post-quantum (PQ) key 15 establishment. 17 About This Document 19 This note is to be removed before publishing as an RFC. 21 Status information for this document may be found at 22 https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/. 24 Discussion of this document takes place on the Transport Layer 25 Security Working Group mailing list (mailto:tls@ietf.org), which is 26 archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe 27 at https://www.ietf.org/mailman/listinfo/tls/. 29 Source for this draft and an issue tracker can be found at 30 https://github.com/tlswg/draft-ietf-tls-mlkem. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 21 March 2027. 49 Copyright Notice 51 Copyright (c) 2026 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 67 3. Key encapsulation mechanisms . . . . . . . . . . . . . . . . 3 68 4. Construction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4.1. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 3 70 4.2. Transmitting encapsulation keys and ciphertexts . . . . . 4 71 4.3. Shared secret calculation . . . . . . . . . . . . . . . . 5 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 ML-KEM [FIPS203] is a FIPS standard for post-quantum [RFC9794] key 83 establishment via a lattice-based key encapsulation mechanism (KEM). 84 This document defines key establishment options for TLS 1.3 via the 85 existing supported_groups (Section 4.3.7 of [RFC9846]) and key_share 86 (Section 4.3.8 of [RFC9846]) extensions. 88 2. Conventions and Definitions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in 93 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 3. Key encapsulation mechanisms 98 This document models key establishment as key encapsulation 99 mechanisms (KEMs), which consist of three algorithms: 101 * KeyGen() -> (pk, sk): A probabilistic key generation algorithm, 102 which generates a public encapsulation key pk and a secret 103 decapsulation key sk. 105 * Encaps(pk) -> (ct, shared_secret): A probabilistic encapsulation 106 algorithm, which takes as input a public encapsulation key pk and 107 outputs a ciphertext ct and shared secret shared_secret. 109 * Decaps(sk, ct) -> shared_secret: A decapsulation algorithm, which 110 takes as input a secret decapsulation key sk and ciphertext ct and 111 outputs a shared secret shared_secret. 113 ML-KEM-512, ML-KEM-768, and ML-KEM-1024 conform to this interface 114 (Table 3 of [FIPS203]): 116 * ML-KEM-512 has encapsulation keys of size 800 bytes, expanded 117 decapsulation keys of 1632 bytes, decapsulation key seeds of size 118 64 bytes, ciphertext size of 768 bytes, and shared secrets of size 119 32 bytes. 121 * ML-KEM-768 has encapsulation keys of size 1184 bytes, expanded 122 decapsulation keys of 2400 bytes, decapsulation key seeds of size 123 64 bytes, ciphertext size of 1088 bytes, and shared secrets of 124 size 32 bytes. 126 * ML-KEM-1024 has encapsulation keys of size 1568 bytes, expanded 127 decapsulation keys of 3168 bytes, decapsulation key seeds of size 128 64 bytes, ciphertext size of 1568 bytes, and shared secrets of 129 size 32 bytes. 131 4. Construction 133 The KEMs are defined as NamedGroups, sent in the supported_groups 134 extension (Section 4.3.7 of [RFC9846]). 136 4.1. Negotiation 138 Each parameter set of ML-KEM is assigned an identifier, registered by 139 IANA in the TLS Supported Groups registry: 141 enum { 143 ..., 145 /* ML-KEM Key Establishment Methods */ 146 mlkem512(0x0200), 147 mlkem768(0x0201), 148 mlkem1024(0x0202) 150 ..., 152 } NamedGroup; 154 4.2. Transmitting encapsulation keys and ciphertexts 156 The public encapsulation key and ciphertext values are each directly 157 encoded with fixed lengths as in [FIPS203]. 159 In TLS 1.3 a KEM public encapsulation key pk or ciphertext ct is 160 represented as a KeyShareEntry as specified in Section 4.3.8 of 161 [RFC9846]. These are transmitted in the extension_data fields of 162 KeyShareClientHello and KeyShareServerHello extensions. 164 For the client's share, the key_exchange value contains the pk output 165 of the corresponding ML-KEM parameter set's KeyGen algorithm. 167 For the server's share, the key_exchange value contains the ct output 168 of the corresponding ML-KEM parameter set's Encaps algorithm. 170 For all parameter sets, the server MUST perform the encapsulation key 171 check described in Section 7.2 of [FIPS203] on the client's 172 encapsulation key, and abort with an illegal_parameter alert if it 173 fails. 175 For all parameter sets, the client MUST check if the ciphertext 176 length matches the selected parameter set, and abort with an 177 illegal_parameter alert if it fails. 179 If ML-KEM decapsulation fails for any other reason, the connection 180 MUST be aborted with an internal_error alert. 182 Implementations MUST NOT reuse randomness in the generation of ML-KEM 183 ciphertexts— it follows that ML-KEM ciphertexts also MUST NOT be 184 reused. 186 During encapsulation, ML-KEM draws the encapsulation randomness from 187 a random bit generator; the peer holding the decapsulation key sk 188 recovers this randomness exactly. Any information that this 189 randomness provides about other outputs of the generator is therefore 190 available to that peer. 192 4.3. Shared secret calculation 194 The fixed-length shared secret output from the ML-KEM Encaps and 195 Decaps algorithms over the appropriate keypair and ciphertext results 196 in the same shared secret shared_secret as its peer, which is 197 inserted into the TLS 1.3 key schedule in place of the (EC)DHE shared 198 secret, as shown in Section 7.1 of [RFC9846]. 200 5. Security Considerations 202 This document defines standalone ML-KEM key establishment for TLS 203 1.3. Use of KEMs for key agreement in TLS 1.3 has been analyzed in 204 multiple settings and security models [DOWLING] [KEMTLS] [HV22] 205 [CHSW22] [CZCJWH25] [ZJZ24]; ML-KEM's IND-CCA security 206 (Indistinguishability under Chosen-Ciphertext Attack) exceeds the 207 requirements for ephemeral key establishment [GHS25] [RFC9846]. 208 Multiple formal analyses, including pen-and-paper computational 209 proofs and machine-checked symbolic analysis using ProVerif 210 [KOBEISSI26], demonstrate that replacing Diffie-Hellman with an IND- 211 CCA-secure KEM preserves the security properties of the TLS 212 handshake. Formal analysis has also shown that hybrid key 213 establishment (e.g., [RFC9954], [RFC10024]) provides compositional 214 security: the exchange remains secure as long as at least one of the 215 component algorithms is unbroken [BJ24] [CPWB25]. 217 TLS 1.3's key schedule commits to the ML-KEM encapsulation key and 218 the ciphertext as the key_exchange field of the key_share extension 219 is populated with those values, which are included as part of the 220 handshake messages. This provides resilience against re- 221 encapsulation attacks against KEMs used for key establishment 222 [CDM23]. 224 [NIST-SP-800-227] includes guidelines and requirements for 225 implementations on using KEMs securely. Implementers are encouraged 226 to use implementations resistant to side-channel attacks, especially 227 those that can be applied by remote attackers. 229 Implementers must evaluate their specific security, performance, and 230 operational constraints when deciding whether to deploy standalone 231 ML-KEM or a hybrid construction. The recommended column in the IANA 232 TLS Supported Groups registry contains the IETF's current guidance on 233 the recommended use of these algorithms for general purposes. 235 The disclosure of the output(s) of an insecure random number 236 generator (RNG) when used in TLS and other protocols can be used in 237 an attack to compromise the state of the insecure RNG itself as 238 described in [DUALECTLS]. The encapsulation randomness in ML-KEM is 239 an additional place where raw RNG output may be disclosed, therefore 240 it is important to follow the RNG guidance in [FIPS203] and 241 [RFC9846]. Implementers can choose to implement mechanisms from 242 [RFC8937] for additional protection across sessions. 244 6. IANA Considerations 246 This document registers three new entries to the TLS Supported Groups 247 registry (https://www.iana.org/assignments/tls-parameters#tls- 248 parameters-8), according to the procedures in Section 6 of [RFC9847]. 250 +========+===========+=======+=============+=========+=============+ 251 |Value |Description|DTLS-OK| Recommended |Reference| Comment | 252 +========+===========+=======+=============+=========+=============+ 253 |512 |MLKEM512 |Y | N |This | FIPS 203 | 254 |(0x0200)| | | |document | version of | 255 | | | | | | ML-KEM-512 | 256 +--------+-----------+-------+-------------+---------+-------------+ 257 |513 |MLKEM768 |Y | N |This | FIPS 203 | 258 |(0x0201)| | | |document | version of | 259 | | | | | | ML-KEM-768 | 260 +--------+-----------+-------+-------------+---------+-------------+ 261 |514 |MLKEM1024 |Y | N |This | FIPS 203 | 262 |(0x0202)| | | |document | version of | 263 | | | | | | ML-KEM-1024 | 264 +--------+-----------+-------+-------------+---------+-------------+ 266 Table 1 268 As defined in Section 3 of [RFC9847], the value N: 270 | Indicates that the item has not been evaluated by the IETF and 271 | that the IETF has made no statement about the suitability of the 272 | associated mechanism. This does not necessarily mean that the 273 | mechanism is flawed, only that no consensus exists. The IETF 274 | might have consensus to leave an item marked as "N" on the basis 275 | of the item having limited applicability or usage constraints. 277 7. References 279 7.1. Normative References 281 [FIPS203] "Module-lattice-based key-encapsulation mechanism 282 standard", National Institute of Standards and Technology 283 (U.S.), DOI 10.6028/nist.fips.203, August 2024, 284 . 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, 288 DOI 10.17487/RFC2119, March 1997, 289 . 291 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 292 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 293 May 2017, . 295 [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol 296 Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, 297 . 299 7.2. Informative References 301 [BJ24] Blanchet, B. and C. Jacomme, "Post-Quantum Sound 302 CryptoVerif and Verification of Hybrid TLS and SSH Key- 303 Exchanges", Proceedings of CSF 2024 , 2024, 304 . 307 [CDM23] Cremers, C., Dax, A., and N. Medinger, "Keeping Up with 308 the KEMs: Stronger Security Notions for KEMs and automated 309 analysis of KEM-based protocols", 2023, 310 . 312 [CHSW22] Celi, S., Hoyland, J., Stebila, D., and T. Wiggers, "A 313 Tale of Two Models: Formal Verification of KEMTLS via 314 Tamarin", Proceedings of ESORICS 2022 , 2022, 315 . 317 [CPWB25] Chen, J., Peng, W., Wang, Y., and Y. Bian, "On the 318 Security and Efficiency of TLS 1.3 Handshake with Hybrid 319 Key Exchange from CPA-Secure KEMs", Entropy 27(12):1242 , 320 2025, . 322 [CZCJWH25] "Post-Quantum {TLS} 1.3 Handshake from {CPA}-Secure {KEMs} 323 with Tighter Reductions", 2025, 324 . 326 [DOWLING] "A Cryptographic Analysis of the TLS 1.3 Handshake 327 Protocol", Journal of Cryptology 2021 , 2020, 328 . 330 [DUALECTLS] 331 "On the Practical Exploitability of Dual EC in TLS 332 Implementations", 2014, 333 . 336 [GHS25] Glabush, L., Hovelmanns, K., and D. Stebila, "On The 337 Multi-target Security of Post-Quantum Key Encapsulation 338 Mechanisms", Cryptology ePrint Archive, Report 2025/343 , 339 2025, . 341 [HV22] Huguenin-Dumittan, L. and S. Vaudenay, "On IND-qCCA 342 Security in the ROM and Its Applications - CPA Security Is 343 Sufficient for TLS 1.3", Proceedings of Eurocrypt 2022 , 344 n.d., . 347 [KEMTLS] Schwabe, P., Stebila, D., and T. Wiggers, "Post-Quantum 348 TLS Without Handshake Signatures", ACM, Proceedings of the 349 2020 ACM SIGSAC Conference on Computer and Communications 350 Security pp. 1461-1480, DOI 10.1145/3372297.3423350, 351 October 2020, . 353 [KOBEISSI26] 354 "FATT Chance: On the Robustness of Standalone and Hybrid 355 ML-KEM Key Exchange in TLS 1.3", n.d., 356 . 358 [NIST-SP-800-227] 359 Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A., 360 Silberg, H., and N. Waller, "Recommendations for key- 361 encapsulation mechanisms", National Institute of Standards 362 and Technology (U.S.), DOI 10.6028/nist.sp.800-227, 363 September 2025, . 365 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 366 and C. Wood, "Randomness Improvements for Security 367 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 368 . 370 [RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for 371 Post-Quantum Traditional Hybrid Schemes", RFC 9794, 372 DOI 10.17487/RFC9794, June 2025, 373 . 375 [RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 376 and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025, 377 . 379 [RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key 380 Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July 381 2026, . 383 [RFC10024] Kwiatkowski, K., Kampanakis, P., Westerbaan, B. E., and D. 384 Stebila, "Post-Quantum Traditional (PQ/T) Hybrid Key 385 Agreement Mechanisms for TLS 1.3", RFC 10024, 386 DOI 10.17487/RFC10024, August 2026, 387 . 389 [ZJZ24] Zhou, B., Jiang, H., and Y. Zhao, "CPA-Secure KEMs are 390 also Sufficient for Post-quantum TLS 1.3", Proceedings of 391 Asiacrypt 2024 , n.d., 392 . 394 Acknowledgments 396 Thanks to Douglas Stebila for consultation on RFC 9954's design, and 397 to Scott Fluhrer, Eric Rescorla, John Preuß Mattsson, Martin Thomson, 398 and Rebecca Guthrie for reviews. 400 Author's Address 402 Deirdre Connolly 403 Selkie Cryptography 404 Email: durumcrustulum@gmail.com