Post-quantum hybrid ECDHE-MLKEM512 Key Agreement for TLSv1.3
draft-rosomakho-tls-ecdhe-mlkem512-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Yaroslav Rosomakho | ||
| Last updated | 2026-07-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rosomakho-tls-ecdhe-mlkem512-00
Transport Layer Security Y. Rosomakho
Internet-Draft Zscaler
Intended status: Informational 5 July 2026
Expires: 6 January 2027
Post-quantum hybrid ECDHE-MLKEM512 Key Agreement for TLSv1.3
draft-rosomakho-tls-ecdhe-mlkem512-00
Abstract
This document defines two post-quantum hybrid key exchange groups for
TLS 1.3 that combine ML-KEM-512 with ECDHE: MLKEM512X25519 and
SecP256r1MLKEM512. These groups provide lower-overhead hybrid key
exchange options for deployments where ClientHello size,
fragmentation risk, constrained-device performance, or compatibility
with existing network infrastructure are important considerations.
The groups defined in this document are intended for use with TLS 1.3
and DTLS 1.3 and follow the hybrid key exchange construction used by
ECDHE-MLKEM key agreement for TLS 1.3.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://yaroslavros.github.io/tls-ecdhe-mlkem512/draft-rosomakho-tls-
ecdhe-mlkem512.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-rosomakho-tls-ecdhe-
mlkem512/.
Discussion of this document takes place on the Transport Layer
Security Working Group mailing list (mailto:tls@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe
at https://www.ietf.org/mailman/listinfo/tls/.
Source for this draft and an issue tracker can be found at
https://github.com/yaroslavros/tls-ecdhe-mlkem512.
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/.
Rosomakho Expires 6 January 2027 [Page 1]
Internet-Draft ECDHE-MLKEM512 hybrid July 2026
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 6 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Motivation and Applicability . . . . . . . . . . . . . . . . 3
4. Hybrid Group Definitions . . . . . . . . . . . . . . . . . . 4
4.1. MLKEM512X25519 . . . . . . . . . . . . . . . . . . . . . 5
4.2. SecP256r1MLKEM512 . . . . . . . . . . . . . . . . . . . . 6
5. Shared Secret Calculation . . . . . . . . . . . . . . . . . . 6
6. Regulatory Context . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. MLKEM512X25519 . . . . . . . . . . . . . . . . . . . . . 8
8.2. SecP256r1MLKEM512 . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
Rosomakho Expires 6 January 2027 [Page 2]
Internet-Draft ECDHE-MLKEM512 hybrid July 2026
1. Introduction
The transition to post-quantum cryptography requires new key exchange
mechanisms for TLS 1.3 [TLS]. Hybrid key exchange combines a post-
quantum key encapsulation mechanism with a traditional elliptic-curve
Diffie-Hellman key exchange, allowing deployments to gain protection
against future cryptographically relevant quantum computers while
retaining the security properties of widely deployed classical key
exchange mechanisms.
[TLS-HYBRID] describes the general design for hybrid key exchange in
TLS 1.3, and [TLS-ECDHE-MLKEM] defines several ECDHE-MLKEM hybrid
groups based on ML-KEM-768 and ML-KEM-1024.
This document defines two additional ECDHE-MLKEM hybrid groups that
use ML-KEM-512:
* MLKEM512X25519
* SecP256r1MLKEM512
This document follows the construction and terminology of
[TLS-HYBRID]. It defines only additional TLS NamedGroup values and
their associated key share encodings. It does not modify the TLS 1.3
handshake, key schedule, or negotiation mechanisms.
2. Conventions and Definitions
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 [TLS] and hybrid key
exchange for TLS 1.3 [TLS-HYBRID].
The term "ML-KEM" refers to the Module-Lattice-Based Key-
Encapsulation Mechanism defined in [FIPS203].
3. Motivation and Applicability
The ECDHE-MLKEM hybrid groups defined in [TLS-ECDHE-MLKEM] are
appropriate for general-purpose post-quantum hybrid deployments and
provide higher post-quantum security categories than ML-KEM-512.
However, the use of ML-KEM-768 or ML-KEM-1024 increases the size of
TLS key shares.
Rosomakho Expires 6 January 2027 [Page 3]
Internet-Draft ECDHE-MLKEM512 hybrid July 2026
Larger key shares increase the size of TLS handshake messages. In
particular, larger client key shares increase the size of the
ClientHello, which can increase the likelihood of fragmentation and
may expose interoperability problems in deployments involving legacy
network devices, middleboxes, or other network infrastructure with
limitations around larger TLS ClientHello messages. Larger key
shares can also increase bandwidth, memory, and computational costs
for constrained endpoints or for deployments operating over lossy or
bandwidth-constrained networks.
The groups defined in this document use ML-KEM-512 in combination
with classical ECDHE key exchange. This provides hybrid post-quantum
and classical key exchange with lower bandwidth, memory, and
computational overhead than corresponding hybrid groups based on ML-
KEM-768 or ML-KEM-1024.
The following table shows the key share sizes for the groups defined
in this document:
+===================+=======================+=======================+
| Group | Client key share size | Server key |
| | | share size |
+===================+=======================+=======================+
| MLKEM512X25519 | 832 bytes | 800 bytes |
+-------------------+-----------------------+-----------------------+
| SecP256r1MLKEM512 | 865 bytes | 833 bytes |
+-------------------+-----------------------+-----------------------+
Table 1
ML-KEM-512 provides a lower post-quantum security category than ML-
KEM-768 and ML-KEM-1024. Deployments that can support hybrid groups
based on ML-KEM-768 or ML-KEM-1024 SHOULD generally prefer those
groups. The groups defined in this document are intended for
constrained, compatibility-sensitive, bandwidth-sensitive, or
otherwise policy-selected deployments.
4. Hybrid Group Definitions
This document defines two additional TLS NamedGroup values for use
with the TLS 1.3 key_share extension:
* MLKEM512X25519
* SecP256r1MLKEM512
Rosomakho Expires 6 January 2027 [Page 4]
Internet-Draft ECDHE-MLKEM512 hybrid July 2026
Each group combines an ML-KEM-512 key exchange with an elliptic-curve
Diffie-Hellman key exchange. The hybrid key exchange values are
encoded as the concatenation of the component key exchange values.
The component encodings are fixed length and are therefore
unambiguous.
For ML-KEM-512, the encapsulation key and ciphertext are encoded as
defined in [FIPS203]. The ML-KEM-512 encapsulation key is 800
octets, and the ML-KEM-512 ciphertext is 768 octets.
For X25519 and secp256r1, the public key encodings used in the
key_share extension are those defined in Section 4.2.8.2 of [TLS].
The X25519 public key is the 32-octet public value for X25519 defined
in Section 5 of [ELLIPTIC-CURVES]. The secp256r1 public key is
encoded as the UncompressedPointRepresentation and is 65 octets.
The server MUST perform the encapsulation key check described in
Section 7.2 of [FIPS203] on the client's ML-KEM-512 encapsulation key
and abort with an illegal_parameter alert if it fails.
The client MUST check that the ML-KEM-512 ciphertext length is 768
octets and abort with an illegal_parameter alert if it fails. If ML-
KEM decapsulation fails for any other reason, the connection MUST be
aborted with an internal_error alert.
Both client and server MUST process the ECDHE component as described
in Section 4.2.8.2 of [TLS], including all validity checks, and abort
with an illegal_parameter alert if it fails.
4.1. MLKEM512X25519
For MLKEM512X25519, the client key_exchange value contains the ML-
KEM-512 encapsulation key followed by the X25519 public key:
struct {
opaque kem_key[800];
opaque ecdhe_key[32];
} MLKEM512X25519ClientShare;
The server key_exchange value contains the ML-KEM-512 ciphertext
followed by the X25519 public key:
struct {
opaque kem_ciphertext[768];
opaque ecdhe_key[32];
} MLKEM512X25519ServerShare;
Rosomakho Expires 6 January 2027 [Page 5]
Internet-Draft ECDHE-MLKEM512 hybrid July 2026
The name MLKEM512X25519 reflects the order of the encoded components
in the key_exchange field: the ML-KEM-512 value is encoded first,
followed by the X25519 value.
4.2. SecP256r1MLKEM512
For SecP256r1MLKEM512, the client key_exchange value contains the
secp256r1 ECDHE public key followed by the ML-KEM-512 encapsulation
key:
struct {
opaque ecdhe_key[65];
opaque kem_key[800];
} SecP256r1MLKEM512ClientShare;
The server key_exchange value contains the secp256r1 ECDHE public key
followed by the ML-KEM-512 ciphertext:
struct {
opaque ecdhe_key[65];
opaque kem_ciphertext[768];
} SecP256r1MLKEM512ServerShare;
The component order for SecP256r1MLKEM512 follows the convention used
by [TLS-ECDHE-MLKEM] for NIST elliptic curves.
5. Shared Secret Calculation
For each group defined in this document, the hybrid shared secret is
the concatenation of the component shared secrets. The resulting
hybrid shared secret is used as the ECDHE shared secret input to the
TLS 1.3 key schedule.
For MLKEM512X25519, the ML-KEM shared secret is produced by ML-
KEM-512 encapsulation and decapsulation, and the X25519 shared secret
is produced by the X25519 Diffie-Hellman operation. The hybrid
shared secret is the concatenation of the ML-KEM shared secret
followed by the X25519 shared secret:
MLKEM512X25519_shared_secret =
MLKEM512_shared_secret || X25519_shared_secret
The ML-KEM-512 shared secret is 32 octets, and the X25519 shared
secret is 32 octets. The resulting hybrid shared secret is therefore
64 octets.
Rosomakho Expires 6 January 2027 [Page 6]
Internet-Draft ECDHE-MLKEM512 hybrid July 2026
For SecP256r1MLKEM512, the ECDHE shared secret is produced by the
secp256r1 Diffie-Hellman operation, and the ML-KEM shared secret is
produced by ML-KEM-512 encapsulation and decapsulation. The hybrid
shared secret is the concatenation of the ECDHE shared secret
followed by the ML-KEM shared secret:
SecP256r1MLKEM512_shared_secret =
SecP256r1_shared_secret || MLKEM512_shared_secret
The secp256r1 shared secret is the x-coordinate of the ECDH shared
secret elliptic curve point represented as an octet string, as
described in Section 7.4.2 of [TLS]. The secp256r1 shared secret is
32 octets, and the ML-KEM-512 shared secret is 32 octets. The
resulting hybrid shared secret is therefore 64 octets.
Both client and server MUST calculate the ECDHE component of the
shared secret as described in Section 7.4.2 of [TLS], including the
all-zero shared secret check for X25519. If this computation or
validation fails, the endpoint MUST abort the connection with an
illegal_parameter alert.
6. Regulatory Context
The regulatory considerations related to component ordering and the
use of hybrid ECDHE-MLKEM key exchange are discussed in Section 5 of
[TLS-ECDHE-MLKEM] and apply to the groups defined in this document.
7. Security Considerations
The security considerations outlined in Section 6 of [TLS-HYBRID] and
Section 6 of [TLS-ECDHE-MLKEM] apply to the groups defined in this
document. This document defines additional ECDHE-MLKEM hybrid groups
and does not change the TLS 1.3 handshake, key schedule,
authentication mechanisms, or the general hybrid key exchange
construction.
The groups defined in this document use ML-KEM-512. ML-KEM-512
provides a lower post-quantum security category than ML-KEM-768 and
ML-KEM-1024. As a result, the groups defined in [TLS-ECDHE-MLKEM]
provide stronger post-quantum security properties and are generally
preferred when their larger key shares and implementation costs are
acceptable.
The groups defined in this document are intended for constrained,
compatibility-sensitive, bandwidth-sensitive, or otherwise policy-
selected deployments where the lower overhead of ML-KEM-512 is
considered an acceptable trade-off.
Rosomakho Expires 6 January 2027 [Page 7]
Internet-Draft ECDHE-MLKEM512 hybrid July 2026
8. IANA Considerations
This document requests/registers two new entries to the TLS Supported
Groups registry (https://www.iana.org/assignments/tls-parameters/tls-
parameters.xhtml#tls-parameters-8), according to the procedures in
Section 6 of [IANA-TLS].
8.1. MLKEM512X25519
Value: TBD1 (0xHEXTBD1)
Description: MLKEM512X25519
DTLS-OK: Y
Recommended: N
Reference: This document
Comment: Combining ML-KEM-512 with X25519 ECDH
8.2. SecP256r1MLKEM512
Value: TBD2 (0xHEXTBD2)
Description: SecP256r1MLKEM512
DTLS-OK: Y
Recommended: N
Reference: This document
Comment: Combining secp256r1 ECDH with ML-KEM-512
9. References
9.1. Normative References
[ELLIPTIC-CURVES]
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>.
[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>.
[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>.
Rosomakho Expires 6 January 2027 [Page 8]
Internet-Draft ECDHE-MLKEM512 hybrid July 2026
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-14, 13 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-14>.
[TLS-ECDHE-MLKEM]
Kwiatkowski, K., Kampanakis, P., Westerbaan, B., and D.
Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement
for TLSv1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-ecdhe-mlkem-05, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
ecdhe-mlkem-05>.
[TLS-HYBRID]
Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key
exchange in TLS 1.3", Work in Progress, Internet-Draft,
draft-ietf-tls-hybrid-design-16, 7 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
hybrid-design-16>.
9.2. Informative References
[IANA-TLS] 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>.
Acknowledgments
The author thanks the authors and contributors of [TLS-HYBRID] and
[TLS-ECDHE-MLKEM], whose work this document builds on.
Author's Address
Yaroslav Rosomakho
Zscaler
Email: yrosomakho@zscaler.com
Rosomakho Expires 6 January 2027 [Page 9]