Summary
-------

Enhance the security of Java applications that require secure network communication by implementing [hybrid key exchange][TLS-HY-DESGN] algorithms for TLS 1.3. Such algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm. Applications that use the `javax.net.ssl` APIs will benefit from these improved algorithms by default, without change to existing code.


Non-Goals
---------

 - It is not a goal to implement hybrid key exchange for any API other than `javax.net.ssl`, nor for any version of TLS other than 1.3.

 - It is not a goal to implement [non-hybrid key exchange schemes for TLS that use ML-KEM][TLS-MLKEM], which would also defend against future quantum computing attacks. We may, however, do that in the future.


Motivation
----------

Quantum computing poses an increasing threat to widely-deployed public-key based encryption 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 defend TLS against this ["harvest now, decrypt later"](https://en.wikipedia.org/wiki/Harvest_now%2C_decrypt_later) threat, the Internet Engineering Task Force (IETF) TLS Working Group has developed a framework for [hybrid key exchange schemes for TLS 1.3][TLS-HY-DESGN]. A hybrid key exchange scheme combines a quantum-resistant algorithm with a traditional algorithm, and is secure as long as one of the algorithms remains unbroken. This approach defends against quantum attacks while acknowledging that these newer algorithms have not yet benefited from the years of testing and analysis already performed on traditional algorithms.

The Java Platform already contains the building blocks for implementing hybrid key exchange schemes with the addition of the KEM API in Java 21 ([JEP 452]) and the ML-KEM algorithm in Java 24 ([JEP 496]). Implementing these hybrid key exchange schemes for TLS is the next step in the platform's support of post-quantum cryptography.

[JEP 452]: https://openjdk.org/jeps/452
[JEP 496]: https://openjdk.org/jeps/496
[RFC 8446]: https://www.rfc-editor.org/rfc/rfc8446
[TLS-HY-DESGN]: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design
[TLS-ECML-KEMS]: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem
[TLS-MLKEM]: https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem


Description
-----------

We will enhance the TLS 1.3 implementation to support [three new post-quantum hybrid key exchange schemes][TLS-ECML-KEMS] that combine [ML-KEM][FIPS203] with the traditional Ephemeral Elliptic-Curve Diffie-Hellman (ECDHE) algorithms:

 - X25519MLKEM768: Hybrid scheme combining ECDHE with [X25519][RFC7748] and ML-KEM-768,
 - SecP256r1MLKEM768: Hybrid scheme combining ECDHE using the secp256r1 curve with ML-KEM-768, and
 - SecP384r1MLKEM1024: Hybrid scheme combining ECDHE using the secp384r1 curve with ML-KEM-1024.

The TLS specification refers to key exchange schemes as "named groups". Accordingly, we will add the names of these schemes to the Named Groups section of the [Java Security Standard Algorithm Names specification][NG-STDNAMES]. The names are the same as those [specified by the IANA].

[FIPS203]: https://csrc.nist.gov/pubs/fips/203/final
[RFC7748]: https://www.rfc-editor.org/rfc/rfc7748
[specified by the IANA]: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
[NG-STDNAMES]: https://docs.oracle.com/en/java/javase/25/docs/specs/security/standard-names.html#named-groups

### Using hybrid key exchange schemes

TLS clients list the key exchange schemes that they support, ordered by preference, in the initial message of the TLS handshake. By default, the `X25519MLKEM768` hybrid scheme will be at the front of that list, making it the most preferred. Thus no changes to existing code will be required in order to benefit from quantum-resistant TLS when it is available, as long as that code does not already select specific key exchange schemes.

The complete default list of schemes will be: `X25519MLKEM768`, `x25519`, `secp256r1`, `secp384r1`, `secp521r1`, `x448`, `ffdhe2048`, `ffdhe3072`, `ffdhe4096`, `ffdhe6144`, and `ffdhe8192`.

You can change the default list of schemes by setting the system property [`jdk.tls.namedGroups`][NGSYSPROP]. You can also select specific schemes by calling the [SSLParameters::setNamedGroups][SSLPARAM] method when configuring a TLS socket connection; for example:

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

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

[NGSYSPROP]: https://docs.oracle.com/en/java/javase/25/security/java-secure-socket-extension-jsse-reference-guide.html#JSSEC-GUID-59D7B06D-5EA4-49EC-9B13-AD7BB166CA45
[SSLPARAM]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#setNamedGroups(java.lang.String%5B%5D)
[RFC8446-SGEXT]: https://www.rfc-editor.org/rfc/rfc8446#section-4.2.7


Alternatives
------------

As mentioned [above](#Non-Goals), we do not propose to implement ML-KEM-based non-hybrid key exchange schemes for TLS. Such pure schemes are another way to defend against future quantum computing attacks. Hybrid schemes, however, are at present in higher demand and give a minimal guarantee of security against both quantum and traditional attacks which neither class of algorithm provides on its own. We may implement pure ML-KEM schemes in future work.


Testing
-------

 - Unit tests will confirm proper operation between client and server using the new hybrid key exchange schemes, and also 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 IETF specifications for [hybrid key exchange in TLS 1.3][TLS-HY-DESGN] and [ECDHE/MLKEM Hybrid][TLS-ECML-KEMS] are still in the draft stage. We will only deliver this feature after these drafts have become standards, by being promoted to RFCs.