*Hi Sean,* Hope you are doing well.
I wanted to get your thoughts on a small enhancement to the default TLS 1.3 named-group configuration introduced by JEP 527. JEP 527 added three hybrid key-exchange groups: - X25519MLKEM768 - SecP256r1MLKEM768 - SecP384r1MLKEM1024 The current default list enables only X25519MLKEM768, while the other two groups can be explicitly enabled through jdk.tls.namedGroups or SSLParameters.setNamedGroups(). I understand and agree with the original rationale for choosing X25519MLKEM768 as the default: it is the fastest hybrid group and has the broadest adoption among existing TLS implementations. However, there is a deployment issue with this configuration in FIPS-constrained environments. When X25519MLKEM768 is unavailable because the underlying X25519 algorithm is not permitted by the active FIPS/provider policy, it is removed from the effective supported named-group list. Since the remaining default groups are classical groups, there is then no PQC hybrid key-exchange group available by default. The current workaround is to explicitly configure jdk.tls.namedGroups to include SecP256r1MLKEM768. This works, but it requires an administrator to know and configure the named-group property consistently across the relevant TLS endpoints. I believe the JDK can avoid this deployment dependency by including SecP256r1MLKEM768 as a second default hybrid group, for example: X25519MLKEM768, SecP256r1MLKEM768, X25519, secp256r1, secp384r1, ... This would preserve the current behavior for the vast majority of deployments: X25519MLKEM768 remains the first and preferred hybrid group. At the same time, when X25519MLKEM768 is unavailable, the already-supported SecP256r1MLKEM768 group would naturally become the next available hybrid option. This seems preferable to requiring administrators to override jdk.tls.namedGroups simply to retain PQC hybrid key exchange in a FIPS-constrained environment. There are a few reasons why SecP256r1MLKEM768 seems particularly suitable for this role: 1. It is already implemented as part of JEP 527; this proposal does not introduce a new hybrid scheme. 2. ML-KEM-768 is the FIPS 203 parameter set already used by X25519MLKEM768. 3. secp256r1 is already an established JDK TLS named group and is part of the current default configuration. 4. X25519MLKEM768 would remain the preferred/default choice whenever it is available, so this does not change the behavior of existing non-FIPS deployments. 5. It provides an automatic alternative when the preferred hybrid group is unavailable, rather than requiring deployment-specific configuration. The intent is therefore not to change the preferred hybrid group, but to make the default configuration resilient to environments where the preferred group cannot be used. Would this be reasonable as a small enhancement to the default named-group list? If there is agreement with this approach, I would be happy to submit a small PR with the corresponding test coverage. -- *Thanks,* *Sibabrata Sahoo*
