Summary

Implement TLS 1.3 hybrid key exchange support for three hybrid named groups (i.e. key exchange schemes): X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 as defined in:

• Hybrid key exchange in TLS 1.3
• Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

These three hybrid named groups combine traditional key exchange schemes such as x25519, secp256r1 and secp384r1 with the post-quantum cryptographic algorithm ML-KEM to form new TLS 1.3 named groups. Applications using javax.net.ssl benefit from these improved algorithms by default without code changes.

Problem

Adversaries can record TLS traffic today and decrypt it later (the "harvest now, decrypt later" threat) when quantum-capable computers become available. Hybrid key exchanges reduce that risk by combining a classical algorithm with a quantum-resistant algorithm.

Solution

During the TLS 1.3 handshake, the client advertises its supported key exchange schemes in the ClientHello message. The order of these key exchange schemes (referred to as named groups in the TLS specifications) is determined by either:

• The default list of supported groups, or
• A custom list specified by the application through the system property jdk.tls.namedGroups or the SSLParameters.setNamedGroups() method. These mechanisms override the default list.

With the introduction of hybrid key exchange, three hybrid schemes will be implemented and one will be added to the top of the default list. The new default list is:

• X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, and ffdhe8192.

The default list of named groups is JDK specific behavior and implemented by the SunJSSE security provider.

The other two hybrid schemes will be available for users to enable via the aforementioned methods. The decision to begin with only X25519MLKEM768 in the default set of named groups is based on the conventions adopted by most browsers and libraries that have already delivered support for hybrid schemes.

Specification

We will add the following standard names for the hybrid groups to the Named Groups section of the Java Security Standard Algorithm Names document:

---------------------  ----------------------------------------------------
Name
---------------------  ----------------------------------------------------

X25519MLKEM768 \       The Post-quantum hybrid ECDHE-MLKEM groups
SecP256r1MLKEM768 \    specified in [draft-ietf-tls-ecdhe-mlkem](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem).
SecP384r1MLKEM1024 \

The URL of the IETF draft above will be replaced by the RFC number when it is published. The addition of these groups to the specification is an SE specific change; however if this feature is backported to earlier JDK releases, these named groups can be used without requiring changes to the Standard Algorithm Names specification due to the following text in the specification:

"Note that an SE implementation may support additional algorithms that are not defined in this specification. As a best practice, if an algorithm is defined in a subsequent version of this specification and an implementation of an earlier specification supports that algorithm, the implementation should use the standard name of the algorithm that is defined in the subsequent specification."