Hi Sean, Thanks for going through it. To answer your last question directly: it was informational input for the "full list of implemented groups is ... (TBD)" line in the issue, not a bug report. There is one concrete correction in it and the rest is measurement offered to help fill that TBD. I should have led with that.
The concrete item: the default list in the issue description still reads eleven, ending ffdhe6144 and ffdhe8192. On 27-ea+32 the default is nine. JDK-8373426 dropped those two from the default when it was resolved on 2026-05-27. As you said, they are still supported, just no longer enabled by default, which is the point: the description's default list, and whatever the guide copies from it, currently overcounts by those two. On ML-KEM-768 and the other standalone ML-KEM entries, I think we agree. I was not arguing to document them. They show up in the enum with a KEM spec and look implemented in a flat listing, but isAvailable is false, so I was flagging them as entries to keep out, not put in. "Explicit about" was the wrong phrase on my part. On the enum generally, understood, and thanks for the JDK-8235710 pointer. The forty entries are not the implemented set, and the removed curves make that clear. I was reading the enum from the outside because getSupportedSSLParameters().getNamedGroups() returns the configured set rather than the implemented one, so the implemented-list TBD has to come from the source either way. That is all I meant by the TBD being awkward, and it ties back to JDK-8388519 rather than being a separate issue. If any of the measurements are useful for the doc work, happy to pass them along. Regards, Arpan Sharma On Tue, Aug 11, 2026 at 4:25 PM Sean Mullan <[email protected]> wrote: > > > > On 7/29/26 2:00 PM, Arpan Sharma wrote: > > 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 > > These are the groups that are enabled *by default*. However, there are > other groups that are supported. > > > 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. > > They are still supported. They are just no longer enabled by default. > > > 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. > > The sun.security.ssl.NamedGroup list does not mean all of these groups > are implemented. In particular, many of the legacy EC curves were > completely removed and there is no longer an implementation for them - > see https://bugs.openjdk.org/browse/JDK-8235710. > > > 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. > > As mentioned above, that is ok. This is not supposed to be a list of all > implemented groups. > > > > > 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. > > I'm not following why you think the guide needs to document groups that > are not implemented yet, such as ML-KEM-768. > > > 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. > > Ok, well that seems right to me. > > > WHY THE TBD IS AWKWARD TO FILL > > Sorry, I don't know what you mean by the above. > > > > > 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. > > I can't really tell if this is just an informational email or you think > you found an issue. If the latter, can you be more specific about what > you think the issue is? > > Thanks, > Sean > > > > > Happy to share the probe, or to re-run any of this on a later EA build > > or another platform. > > > > Regards, > > Arpan Sharma >
