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, . [FIPS203] "Module-lattice-based key-encapsulation mechanism standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.203, August 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . [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, . 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, . 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]