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

Summary

Enhance the security of Java applications that use Transport Layer Security (TLS) 1.3 by providing support for Hybrid Key Exchange algorithms. Hybrid key exchange algorithms protect applications using TLS against future quantum computer attacks by combining two algorithms, one quantum-resistant and one traditional. Applications using TLS 1.3 and the javax.net.ssl APIs will benefit from the enhanced security by default, requiring no code changes.

Non-Goals

• It is not a goal to provide a hybrid key exchange implementation for use with any other APIs other than the javax.net.ssl APIs.
• It is not a goal to support this feature on earlier versions of TLS such as TLS 1.2.
• 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

Quantum computing poses an increasing threat to widely-deployed public-key based algorithms such as Rivest-Shamir-Adelman (RSA) and Elliptic-Curve Diffie-Hellman (ECDH). Switching to quantum-resistant algorithms is urgent even though large-scale quantum computers that can break these algorithms do not yet exist, since an adversary could harvest encrypted data today, store it, and decrypt it once such computers become available.

In order to address this "harvest now, decrypt later" threat model for TLS, the Internet Engineering Task Force (IETF) TLS Working Group has developed a framework for hybrid key exchange schemes for TLS 1.3. Hybrid key exchange schemes combine traditional algorithms with quantum-resistant ones, and are secure as long as one of the algorithms remains unbroken. 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.

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 in TLS 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 post-quantum hybrid key exchange schemes that combine ML-KEM with the traditional Ephemeral Elliptic-Curve Diffie-Hellman (ECDHE) algorithms:

• 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" (the term used for key exchange schemes in the TLS specification) section of the Java Security Standard Algorithm Names specification. The names are consistent with those specified on the IANA TLS Parameters site.

Using Hybrid Key Exchange Schemes

TLS clients list the key exchange schemes they support, ordered by preference, during the initial message exchange of the TLS handshake. By default, the hybrid schemes will be added to the front of the list of supported schemes, making them the most-preferred. The complete set of default schemes will be: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096.

The order of the schemes can be changed by setting the jdk.tls.namedGroups System property or by calling the SSLParameters.setNamedGroups() method.

In the following example, the schemes 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 algorithm support 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 pure ML-KEM 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().
• Testing against other TLS implementations that support hybrid schemes will confirm interoperability.

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). We will only deliver this feature after these drafts have become standards.