Hello,
JDK-8378868 ("Document the named groups in the SunJSSE section of JDK
Providers guide") is open with a TBD for the list of implemented groups.
I ran some measurements against 27-ea+32 that may be useful input, and
one of them suggests the default list in the issue description has since
changed.
All figures are from openjdk-27-ea+32_macos-aarch64 (build
27-ea+32-2315). Early access, so these may still change before GA.
DEFAULT NAMED GROUPS
The default named groups are these nine:
X25519MLKEM768, x25519, secp256r1, secp384r1, secp521r1, x448,
ffdhe2048, ffdhe3072, ffdhe4096
Three independent paths agree on that list:
getDefaultSSLParameters().getNamedGroups() on SSLContext.getDefault(),
"java -XshowSettings:security:tls" under "Enabled Named Groups", and
NamedGroup.SupportedGroups.defaultGroups in the source.
The issue description lists eleven, ending "ffdhe4096, ffdhe6144, and
ffdhe8192". JDK-8373426 removed those two and was resolved on
2026-05-27, nearly three months after this description was written,
which would account for it.
X25519MLKEM768 is first in preference order. SecP256r1MLKEM768 and
SecP384r1MLKEM1024 are implemented but not in the default list, as JEP
527 states.
THE ENUM BY PROTOCOL APPLICABILITY
sun.security.ssl.NamedGroup has 40 entries in this build. By declared
protocol range:
- PROTOCOLS_TO_12 (24): the 14 sect* curves, secp160k1/r1/r2,
secp192k1/r1, secp224k1/r1, secp256k1, and the two arbitrary_explicit_*
pseudo-entries.
- PROTOCOLS_TO_13 (10): secp256r1, secp384r1, secp521r1, x25519, x448,
ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192.
- PROTOCOLS_OF_13 (6): MLKEM512, MLKEM768, MLKEM1024, X25519MLKEM768,
SecP256r1MLKEM768, SecP384r1MLKEM1024.
If the guide documents implemented groups, splitting them this way may
be more useful than a flat list, since 24 of the 40 cannot appear in a
TLS 1.3 handshake at all.
WHICH ENTRIES ARE ACTUALLY AVAILABLE
isAvailable is derived in the constructor from keAlgParamSpec being
non-null, followed by a service lookup. Five of the 40 entries are
unavailable: MLKEM512, MLKEM768 and MLKEM1024 (declared with a null
parameter spec, so isAvailable is false by construction), plus
arbitrary_explicit_prime_curves and arbitrary_explicit_char2_curves.
Setting -Djdk.tls.namedGroups to a single name confirms this from
outside: those five raise "contains no supported named groups", the
other 35 are accepted.
The standalone ML-KEM entries are the case I would most want the guide
to be explicit about. They carry codepoints 0x0200-0x0202 (IANA 512-514,
registered by draft-connolly-tls-mlkem-key-agreement and marked
Recommended=N) and NamedGroupSpec.NAMED_GROUP_KEM, so they look like
implemented groups in a listing, but they are placeholders, which fits
their draft, non-recommended status. Note this is specific to the TLS
named group: the JDK does implement the algorithm itself, and
KEM.getInstance("ML-KEM-768") and
KeyPairGenerator.getInstance("ML-KEM-768") both succeed on the same
build.
TLS 1.3 NEGOTIATION
Restricting jdk.tls.namedGroups to a single name and running a TLS 1.3
handshake between a JDK client and a JDK server in that JVM: sect163k1,
secp192r1 and secp256k1 fail, as their TO_12 declaration implies;
ffdhe6144 succeeds (implemented, just not default); and X25519MLKEM768,
SecP256r1MLKEM768 and SecP384r1MLKEM1024 all succeed. So all three JEP
527 hybrids are implemented and negotiable here; two are only off by
default.
WHY THE TBD IS AWKWARD TO FILL
getSupportedSSLParameters().getNamedGroups() returns the same nine
entries as getDefaultSSLParameters(), not the implemented set. With
-Djdk.tls.namedGroups=SecP256r1MLKEM768 both return exactly
[SecP256r1MLKEM768]. XshowSettings follows the property the same way,
though it is labelled "Enabled Named Groups", which is accurate. So the
"supported" accessor reports what is configured, and nothing public
reports what SunJSSE implements. That is the gap in JDK-8388519, and it
is why the figures above come from reading the enum and probing the
system property rather than from asking the provider.
Happy to share the probe, or to re-run any of this on a later EA build
or another platform.
Regards,
Arpan Sharma
