Post-quantum hybrid ECDHE-MLKEM512 Key Agreement for TLSv1.3

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 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

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.¶

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:¶

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¶

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.¶

struct {
    opaque kem_key[800];
    opaque ecdhe_key[32];
} MLKEM512X25519ClientShare;

struct {
    opaque kem_ciphertext[768];
    opaque ecdhe_key[32];
} MLKEM512X25519ServerShare;

struct {
    opaque ecdhe_key[65];
    opaque kem_key[800];
} SecP256r1MLKEM512ClientShare;

struct {
    opaque ecdhe_key[65];
    opaque kem_ciphertext[768];
} SecP256r1MLKEM512ServerShare;

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.¶

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.¶

8. IANA Considerations

This document requests/registers two new entries to the TLS Supported Groups registry, according to the procedures in Section 6 of [IANA-TLS].¶

9. References

Acknowledgments

The author thanks the authors and contributors of [TLS-HYBRID] and [TLS-ECDHE-MLKEM], whose work this document builds on.¶

Author's Address