JDK-8369848 : Implement JEP 527: TLS 1.3 Hybrid Key Exchange
  • Type: CSR
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P2
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 27
  • Submitted: 2025-10-14
  • Updated: 2025-12-09
  • Resolved: 2025-12-09
Related Reports
CSR :  
JDK-8314323 - Implement JEP 527: TLS 1.3 Hybrid Key Exchange
Description
Summary
-------
Implement TLS 1.3 hybrid key exchange support for three hybrid named groups (i.e. cryptographic key exchange schemes): `X25519MLKEM768`, `SecP256r1MLKEM768`, and `SecP384r1MLKEM1024` as defined in:

 - [Hybrid key exchange in TLS 1.3][1]
 - [Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3][2]

These three hybrid named groups combine traditional cryptographic key exchange schemes such as x25519, secp256r1 and secp384r1 with the post-quantum cryptographic algorithm [ML-KEM][3] to form new TLS 1.3 named groups. Applications using `javax.net.ssl` (JSSE) 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"][4] threat) when quantum-capable computers become available. Hybrid key exchanges reduce that risk by combining a classical cryptographic 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][5] document, along with minor edits to existing lines for formatting consistency and clarity:

```
diff --git a/closed/src/java.base/share/specs/security/standard-names.md b/closed/src/java.base/share/specs/security/standard-names.md
index 1ff7a3b912b4910e86326ca6b9754d2f8b602995..139a3feedcf761470694f6c31509205bbd88ceda 100644
--- a/closed/src/java.base/share/specs/security/standard-names.md
+++ b/closed/src/java.base/share/specs/security/standard-names.md
@@ -2629,26 +2629,31 @@ rsa_pss_rsae_sha512     [RFC 8446](https://tools.ietf.org/html/rfc8446)
 
 The following table contains the standard group names, which are
 the named groups used in key exchange algorithms of TLS connections and are also
-defined in the [Supported Groups section](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8)
-of the IANA TLS Registry.
-
-----------------  ----------------------------------------------------
-Name
-----------------  ----------------------------------------------------
-secp256r1 \       The NIST elliptic curves as specified in
-secp384r1 \       [RFC 8422](https://tools.ietf.org/html/rfc8422).
+defined in the [TLS Supported Groups](
+https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8)
+section.
+
+---------------------  ----------------------------------------------------
+Name                   Description
+---------------------  ----------------------------------------------------
+secp256r1 \            The NIST elliptic curves as specified in
+secp384r1 \            [RFC 8422](https://tools.ietf.org/html/rfc8422).
 secp521r1
 
-x25519 \          The elliptic curves as specified in
-x448 \            [RFC 8446](https://tools.ietf.org/html/rfc8446) and
-                  [RFC 8442](https://tools.ietf.org/html/rfc8422).
+x25519 \               The elliptic curves as specified in
+x448 \                 [RFC 8446](https://tools.ietf.org/html/rfc8446) and
+                       [RFC 8442](https://tools.ietf.org/html/rfc8422).
+
+X25519MLKEM768 \       The post-quantum hybrid ECDHE-MLKEM groups as
+SecP256r1MLKEM768 \    specified in [draft-ietf-tls-ecdhe-mlkem](
+SecP384r1MLKEM1024 \   https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem).
 
-ffdhe2048 \       The Finite Field Diffie-Hellman Ephemeral (FFDHE)
-ffdhe3072 \       groups as specified in
-ffdhe4096 \       [RFC 7919](https://tools.ietf.org/html/rfc7919).
+ffdhe2048 \            The Finite Field Diffie-Hellman Ephemeral (FFDHE)
+ffdhe3072 \            groups as specified in
+ffdhe4096 \            [RFC 7919](https://tools.ietf.org/html/rfc7919).
 ffdhe6144 \
 ffdhe8192
-----------------  ----------------------------------------------------
+---------------------  ----------------------------------------------------
 

 ```

The URL of the IETF draft above will be updated to the URL of the RFC when 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."


  [1]: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
  [2]: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
  [3]: https://csrc.nist.gov/pubs/fips/203/final
  [4]: https://en.wikipedia.org/wiki/Harvest_now%2C_decrypt_later
  [5]: https://docs.oracle.com/en/java/javase/25/docs/specs/security/standard-names.html#named-groups
Comments
Moving to Approved.
09-12-2025
[~darcy] The most important of the two specifications (the Hybrid key exchange in TLS 1.3) did have some very late stage discussions that has extended its time in draft, but I it hasn't resulted in substantive technical changes that affect the behavior of the feature. As of today it is in the late stages of the RFC Editor queue, which I believe means it could become an RFC "any day, now" (though when exactly I cannot say). As with the first RFC, the second (the ECDHE-MLKEM forms of hybrid named groups) also went through some late-stage discussions. Again, it didn't seem to result in any changes that affect the key calculations for these hybrid KEMs. The state right now is a few steps behind the first one. Basically formal publication has been requested for this draft, but there are still a few stages that will go through before actually becoming an RFC. It seems unlikely at this point, especially considering the late-stage discussions both had and completed (without changes that affect this feature directly), that there will be further hitches to the process.
04-12-2025
Moving to Provisional, not Approved. [~hchao], what is the status of the external RFC and if affects, if any, would changes in the RFC have on this work?
04-12-2025