JEP draft: Post-Quantum Hybrid Key Exchange for TLS 1.3

Summary

Enhance the JDK's implementation of Transport Layer Security (TLS) 1.3 to support Hybrid Key Exchange and implement three schemes that each use a quantum-resistant Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) algorithm as one component. Hybrid key exchange combines multiple algorithms to establish a shared secret and is secure as long as one of the algorithms remains unbroken.

Non-Goals

• It is not a goal to provide a hybrid key exchange implementation for use outside TLS 1.3.
• It is not a goal to add support for non-hybrid key exchange schemes that use ML-KEM. We may, however, do that in follow-on work.

Motivation

Establishing a secure connection with TLS involves a handshake, which is performed as part of the process of connecting an SSLSocket or SSLServerSocket to its TLS peer. The key exchange step in a TLS handshake establishes a shared secret key from which encryption keys are derived. The key exchange step is based on traditional public key algorithms such as Diffie-Hellman which are vulnerable to attacks mounted by a future, large-scale quantum computer. In particular, TLS sessions today can be recorded and then fed to a quantum computer for decryption at a later date (sometimes referred to as "harvest now, decrypt later").

The Internet Engineering Task Force (IETF) TLS Working Group is addressing this threat by defining hybrid key exchange schemes for TLS 1.3. These schemes combine traditional key exchange algorithms with quantum-resistant ones. This approach provides the benefit of quantum-resistant security while acknowledging that these newer algorithms have not had years of analysis performed on them like traditional algorithms have. Three hybrid key exchange schemes have been defined that combine ML-KEM with traditional elliptic curve Diffie-Hellman. The Java Platform already contains the building blocks for implementing hybrid key exchange schemes with the addition of the KEM API in JDK 21 and the ML-KEM algorithm in JDK 24. Implementing these hybrid key exchange schemes is a necessary next-step in the Java Platform's support of post-quantum cryptography.

Description

We will enhance the TLS 1.3 implementation to support three new hybrid key exchange schemes that combine ML-KEM with the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) algorithm:

• X25519MLKEM768: Hybrid scheme combining ECDHE with X25519 and ML-KEM-768
• SecP256r1MLKEM768: Hybrid scheme combining ECDHE using the secp256r1 curve with ML-KEM-768
• SecP384r1MLKEM1024: Hybrid scheme combining ECDHE using the secp384r1 curve with ML-KEM-1024

These schemes will be added to the "Named Groups" section of the Java Security Standard Algorithm Names specification. These new named group String names are consistent with those specified on the IANA TLS Parameters site.

Using Hybrid Named Groups

TLS clients communicate the named groups which they support, ordered by preference, in the Supported Groups extension of the ClientHello message. The default set of named groups currently sent by the Java TLS 1.3 client are the following: x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192.

The hybrid named groups will be added to this list. The preference order has not yet been decided. The default list of named groups can be changed by setting the jdk.tls.namedGroups system property or by calling the SSLParameters.setNamedGroups method.

In the following example, the named groups are set so the client will enable two hybrid and two traditional key exchange schemes:

SSLSocket tlsSock = (SSLSocket)(SSLContext.getDefault().
        getSocketFactory().createSocket());
SSLParameters params = tlsSock.getSSLParameters();

// Configure the socket to use two hybrid KEM schemes and
// two traditional ones
params.setNamedGroups(new String[] { "SecP256r1MLKEM768",
        "X25519MLKEM768", "secp256r1", "x25519" });
tlsSock.setSSLParameters(params);

Alternatives

We will not deliver pure ML-KEM based key exchange support as part of this JEP. These key exchange schemes are another way to introduce quantum-resistant schemes into the TLS protocol. Hybrid schemes are in higher demand and give a minimal guarantee of security against both traditional and post-quantum attacks that neither class of algorithm has on its own. We may support these schemes in follow-on work.

Testing

• Unit tests will confirm the proper operation between client and server using the new hybrid key exchange schemes, and also the proper operation when these new named groups are asserted via the jdk.tls.namedGroups System property or via SSLParameters.setNamedGroups().
• Interoperability testing will be performed against other TLS implementations that support hybrid schemes.

Risks and Assumptions

The Hybrid key exchange in TLS 1.3 and ECDHE/MLKEM Hybrid Internet Drafts have not yet reached standardization (promoted to RFCs). Ideally the standards should be finalized before we deliver this feature.