Internet-Draft MLS Cipher Suites with ML-KEM July 2025
Mahy & Barnes Expires 8 January 2026 [Page]
Workgroup:
MLS
Internet-Draft:
draft-mahy-mls-pq-01
Published:
Intended Status:
Informational
Expires:
Authors:
R. Mahy
Rohan Mahy Consulting Services
R. L. Barnes
Cisco

ML-KEM and Hybrid Cipher Suites for Messaging Layer Security

Abstract

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

This note is to be removed before publishing as an RFC.

Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mahy-mls-pq/.

Discussion of this document takes place on the MLS Working Group mailing list (mailto:mls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mls/. Subscribe at https://www.ietf.org/mailman/listinfo/mls/.

Source for this draft and an issue tracker can be found at https://github.com/rohanmahy/mahy-mls-xwing/.

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 8 January 2026.

Table of Contents

1. 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 [RFC9420].

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) [MLKEM] together with appropriate symmetric algorithms and traditional signature algorithms. These cipher suites address the risk of "harvest now, decrypt later" attacks, while not taking on the additional cost of post-quantum signatures.

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:

For all the cipher suites defined in this document, we use AES256 GCM [GCM] as the Authenticated Encryption with Authenticated Data (AEAD) [RFC5116] algorithm; HMAC [RFC2104] with SHA-384 [SHS] as the hash function; and XOF(SHAKE256) (Section 3.2 of [FIPS202]) as the Key Derivation Function (KDF).

For the PQ/T hybrid KEMs and the pure ML-KEM HPKE integration, we use the KEMs defined in [I-D.ietf-hpke-pq].

2. IANA Considerations

2.1. 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:

Table 1
Value Name Rec Reference
TBD1 MLS_128_KitchenSink-KEM(ML-KEM-768,X25519)_AES256GCM_SHA384_Ed25519 Y RFCXXXX
TBD2 MLS_128_QSF-KEM(ML-KEM-768,P-256)_AES256GCM_SHA384_P256 Y RFCXXXX
TBD3 MLS_192_QSF-KEM(ML-KEM-1024,P-384)_AES256GCM_SHA384_P384 Y RFCXXXX
TBD4 MLS_128_ML_KEM_768_AES256GCM_SHA384_P256 Y RFCXXXX
TBD5 MLS_192_ML_KEM_1024_AES256GCM_SHA384_P384 Y RFCXXXX

The mapping of cipher suites to HPKE primitives [I-D.ietf-hpke-hpke], HMAC hash functions, and TLS signature schemes [RFC8446] is as follows:

Table 2
Value KEM KDF AEAD Hash Signature
0xTBD1 0x0051 0x0011 0x0002 SHA384 ed25519
0xTBD2 0x0050 0x0011 0x0002 SHA384 ecdsa_secp256r1_sha256
0xTBD3 0x0052 0x0011 0x0002 SHA384 ecdsa_secp384r1_sha384
0xTBD4 0x0041 0x0011 0x0002 SHA384 ecdsa_secp256r1_sha256
0xTBD5 0x0042 0x0011 0x0002 SHA384 ecdsa_secp384r1_sha384

The hash used for the MLS transcript hash is the one referenced in the cipher suite name. "SHA384" refers to the SHA-384 functions defined in [SHS].

3. Security Considerations

This 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. Cipher suites using post-quantum secure signature algorithms may be defined in the future.

For security considerations related to the KEMs used in this document, please see the documents that define those KEMs [I-D.ietf-hpke-pq] and [I-D.irtf-cfrg-hybrid-kems].

4. References

4.1. Normative References

[FIPS202]
"SHA-3 standard :: permutation-based hash and extendable-output functions", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.202, , <https://doi.org/10.6028/nist.fips.202>.
[GCM]
Dworkin, M., "Recommendation for block cipher modes of operation :: GaloisCounter Mode (GCM) and GMAC", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-38d, , <https://doi.org/10.6028/nist.sp.800-38d>.
[I-D.ietf-hpke-hpke]
Barnes, R., Bhargavan, K., Lipp, B., and C. A. Wood, "Hybrid Public Key Encryption", Work in Progress, Internet-Draft, draft-ietf-hpke-hpke-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-hpke-hpke-01>.
[I-D.ietf-hpke-pq]
Barnes, R., "Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE", Work in Progress, Internet-Draft, draft-ietf-hpke-pq-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-hpke-pq-01>.
[MLKEM]
"Module-lattice-based key-encapsulation mechanism standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.203, , <https://doi.org/10.6028/nist.fips.203>.
[RFC2104]
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, , <https://www.rfc-editor.org/rfc/rfc2104>.
[RFC5116]
McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, , <https://www.rfc-editor.org/rfc/rfc5116>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9420]
Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, , <https://www.rfc-editor.org/rfc/rfc9420>.
[SHS]
"Secure hash standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.180-4, , <https://doi.org/10.6028/nist.fips.180-4>.

4.2. Informative References

[I-D.irtf-cfrg-hybrid-kems]
Connolly, D., "Hybrid PQ/T Key Encapsulation Mechanisms", Work in Progress, Internet-Draft, draft-irtf-cfrg-hybrid-kems-03, , <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hybrid-kems-03>.

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.

Authors' Addresses

Rohan Mahy
Rohan Mahy Consulting Services
Richard L. Barnes
Cisco