Hi Siba,
Nice to hear from you.
Yes, we are aware of this issue. That is, a strict FIPS module cannot
provide X25519 as a standalone algorithm as it is not allowed by FIPS
140-3. But it can employ X25519 in the context of X25519MLKEM768 which
is still FIPS 140-3 compliant, as specified in NIST SP 800-227 [1].
Our preferred way to fix this is to implement support for Hybrid Key
Exchange Providers [2]. JCE providers will implement the hybrid
algorithms directly. This should satisfy the FIPS compliance requirement.
HTH,
Sean
[1] https://csrc.nist.gov/pubs/sp/800/227/ipd
[2] https://bugs.openjdk.org/browse/JDK-8385968
On 8/12/26 1:52 PM, Sibabrata Sahoo wrote:
*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/
