]>

rohan.ietf@gmail.com

rlb@ipv.sx

sec MLS ML-KEM Kyber post-quantum post quantum KEM KEM PQ/T hybrid hybrid KEM Key Exchange Mechanism This document registers new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers. These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the MLS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The potential availability of a cryptographically-relevant quantum computer has caused concern that well-funded adversaries could overturn long-held assumptions about the security assurances of classical Key Exchange Mechanisms (KEMs) and classical cryptographic signatures, which are fundamental to modern security protocols, including the MLS protocol . Of particular concern are "harvest now, decrypt later" attacks, by which an attacker could collect encrypted traffic now, before a quantum computer exists, and later use a quantum computer to break the confidentiality protections on the collected traffic. In response to these concerns, the cryptographic community has defined "post-quantum" algorithms, which are designed to be resilient to attacks by quantum computers. Symmetric algorithms can be made post-quantum secure simply by using longer keys and hashes. For asymmetric operations such as KEMs and signatures, entirely new algorithms are needed. In this document, we define ciphersuites that use the post-quantum secure Module-Lattice-Based KEM (ML-KEM) together with appropriate symmetric algorithms, and either traditional or Module-Lattice-Based Digital Signature Algorithm (ML-DSA) post-quantum signature algorithms. The traditional signature cipher suites address the risk of "harvest now, decrypt later" attacks, while not taking on the additional cost of post-quantum signatures. The cipher suites with post-quantum signatures use only post-quantum KEMs.

Post-quantum KEM Cipher Suites Following the pattern of base MLS, we define several variations, to allow for users that prefer to only use NIST-approved cryptography, users that prefer a higher security level, and users that prefer a PQ/traditional hybrid KEM over pure ML-KEM:

• ML-KEM-768 + X25519 (128-bit security, Non-NIST, PQ/T hybrid KEM)
• ML-KEM-768 + P-256 (128-bit security, NIST, PQ/T hybrid KEM)
• ML-KEM-1024 + P-384 (192-bit security, NIST, PQ/T hybrid KEM)
• ML-KEM-768 (128-bit security, Non-NIST, pure PQ KEM)
• ML-KEM-768 (128-bit security, NIST, pure PQ KEM)
• ML-KEM-1024 (192-bit security, NIST, pure PQ KEM)
• ML-KEM-768 + X25519 (128-bit security, Non-NIST, PQ/T hybrid KEM + PQ signature)
• ML-KEM-768 (192-bit security, NIST, pure PQ)
• ML-KEM-1024 (256-bit security, NIST, pure PQ)

Some parts of the community wish to support the 128-bit security level with the same Authenticated Encryption with Authenticated Data (AEAD) algorithms and hash function as used in the default cipher suite registered in (AES128 GCM and HMAC with SHA-256 ), while other parts of the community would like to follow recent recommendations to transition immediately to AES256 GCM and HMAC with SHA-384 . For the cipher suites at the 192-bit or 256-bit security levels, we use AES256 GCM as the AEAD algorithm, and HMAC with SHA-384 as the hash function. ML-KEM uses the SHAKE and SHA-3 algorithms internally (see Section 4.1 of ). Likewise the three hybrid KEMs used in this document use SHAKE as a Pseudo-Random Generator (PRG) and SHA-3 as a Key Derivation Function (KDF) inside the hybrid combiner. MLS extensively uses the two-stage KDF functions Extract and Expand defined in to derive keys in the ratchet tree , the key schedule , and the secret tree . In particular, MLS uses the Extract function to incorporate commit secrets and pre-shared keys into the key schedule. As does not define either function for "single-stage" KDFs like SHAKE (see ), the cipher suites defined here use the HMAC-based KDF (HKDF) algorithms HKDF-SHA384 and HKDF-SHA256 for the KDF functions used inside MLS. Finally, one of cipher suites at the 128-bit security level, uses the same hybrid KEM as the first cipher suite, the ChaCha20-Poly130 AEAD algorithm, HMAC with SHA-384, and the pure PQ signature algorithm ML-DSA-44. The choice of ChaCha20-Poly130 was selected for acceptable performance when implemented entirely in software. For the PQ/T hybrid KEMs and the pure ML-KEM HPKE integration, we use the KEMs defined in . The signature schemes for ML-DSA-44, ML-DSA-65, and ML-DSA-87 are defined in .

IANA Considerations

MLS Cipher Suites This document requests that IANA add the following entries to the "MLS Cipher Suites" registry, replacing "XXXX" with the RFC number assigned to this document:

Value	Name	Rec	Reference
TBD1	MLS_128_MLKEM768X25519_AES128GCM_SHA256_Ed25519	Y	RFCXXXX
TBD2	MLS_128_MLKEM768X25519_AES256GCM_SHA384_Ed25519	Y	RFCXXXX
TBD3	MLS_128_MLKEM768P256_AES128GCM_SHA256_P256	Y	RFCXXXX
TBD4	MLS_128_MLKEM768P256_AES256GCM_SHA384_P256	Y	RFCXXXX
TBD5	MLS_192_MLKEM1024P384_AES256GCM_SHA384_P384	Y	RFCXXXX
TBD6	MLS_128_MLKEM768_AES256GCM_SHA384_Ed25519	Y	RFCXXXX
TBD7	MLS_128_MLKEM768_AES256GCM_SHA384_P256	Y	RFCXXXX
TBD8	MLS_192_MLKEM1024_AES256GCM_SHA384_P384	Y	RFCXXXX
TBD9	MLS_128_MLKEM768X25519_CHACHA20POLY1305_SHA384_MLDSA44	Y	RFCXXXX
TBD10	MLS_192_MLKEM768_AES256GCM_SHA384_MLDSA65	Y	RFCXXXX
TBD11	MLS_256_MLKEM1024_AES256GCM_SHA384_MLDSA87	Y	RFCXXXX

The mapping of cipher suites to HPKE primitives , HMAC hash functions, and TLS signature schemes is as follows:

Value	KEM	KDF	AEAD	Hash	Signature
TBD1	0x647a	0x0001	0x0001	SHA256	ed25519
TBD2	0x647a	0x0002	0x0002	SHA384	ed25519
TBD3	0x0050	0x0001	0x0001	SHA256	ecdsa_secp256r1_sha256
TBD4	0x0050	0x0002	0x0002	SHA384	ecdsa_secp256r1_sha256
TBD5	0x0051	0x0002	0x0002	SHA384	ecdsa_secp384r1_sha384
TBD6	0x0041	0x0002	0x0002	SHA384	ed25519
TBD7	0x0041	0x0002	0x0002	SHA384	ecdsa_secp256r1_sha256
TBD8	0x0042	0x0002	0x0002	SHA384	ecdsa_secp384r1_sha384
TBD9	0x647a	0x0002	0x0003	SHA384	mldsa44
TBD10	0x0041	0x0002	0x0002	SHA384	mldsa65
TBD11	0x0042	0x0002	0x0002	SHA384	mldsa87

The hash used for the MLS transcript hash is the one referenced in the cipher suite name. "SHA256" and "SHA384" refer to the SHA-256 and SHA-384 functions defined in .

Security Considerations The first eight ciphersuites defined in this document combine a post-quantum (or PQ/T hybrid) KEM with a traditional signature algorithm. As such, they are designed to provide confidentiality against quantum and classical attacks, but provide authenticity against classical attacks only. Thus, these cipher suites do not provide full post-quantum security, only post-quantum confidentiality. The last three cipher suites also use post-quantum signature algorithms. For security considerations related to the KEMs used in this document, please see the documents that define those KEMs and . For security considerations related to the post-quantum signature algorithms used in this document, please see and .

Normative References National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology (U.S.) National Institute of Standards and Technology Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind SandboxAQ Cisco PQ/T Hybrid Key Encapsulation Mechanisms (KEMs) combine "post- quantum" cryptographic algorithms, which are safe from attack by a quantum computer, with "traditional" algorithms, which are not. CFRG has developed a general framework for creating hybrid KEMs. In this document, we define concrete instantiations of this framework to illustrate certain properties of the framework and simplify implementors' choices. Inria Rosenpass This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric Key Encapsulation Mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. This document provides instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA-2. This document obsoletes RFC 9180. Cisco Selkie Cryptography Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section. DigiCert Google Cloudflare This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. Independent This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. SandboxAQ Cisco University of Michigan This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a post-quantum (PQ) KEM with a traditional cryptographic component. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described.

Acknowledgments This work would not be possible without the hard work of the CFRG Hybrid KEM design team: Aron Wussler, Bas Westerbaan, Deirdre Connolly, Mike Ounsworth, Nick Sullivan, and Stephen Farrell. Thanks also to Joël Alwen, Marta Mularczyk, and Britta Hale.