On 7/23/26 6:51 PM, Arpan Sharma wrote:
> You probably already know this, but you can set only PQC or hybrid
> named groups if you don't want classical groups to be used.
I tested that guard too, and it has a sharp edge worth noting: with
setNamedGroups({"MLKEM768"}) alone on a JDK that does not support it,
the call succeeds and nothing fails locally. The client still sends a
ClientHello — with no supported_groups or key_share extension at all
— and the failure surfaces only as the peer's fatal alert, whose type
depends on the peer (a Bouncy Castle 1.84 server produced
handshake_failure; in an earlier test a stock JSSE server produced
missing_extension). So the connection does fail closed, but remotely
and in a way that is hard to attribute to the dropped group. The
supported-groups query API in JDK-8388519 gives applications the
right tool here: check first, then set.
That does seem a bit odd. We'll take a closer look at that case and see
if it needs to be addressed better.
On that API, one data point that may be useful for the RFE: on
26.0.1 and 27-ea, SSLContext.getSupportedSSLParameters()
.getNamedGroups() already returns the provider's supported list (my
reproducer uses it as its baseline). But as far as I can tell the
getSupportedSSLParameters() spec only guarantees that the ciphersuite
and protocol arrays are populated, so an application cannot rely on
it across providers — a first-class API in the style of
getSupportedCipherSuites would give that query an actual contract.
getSupportedCipherSuites() is also provider specific. It returns all the suites
that a provider implements and can be negotiated.
SSLContext.getSupportedSSLParameters().getNamedGroups() only returns the groups
that the provider would send to the server by default,
for example in the supported_groups extension. There can be other groups that
the provider may implement but not send by default,
and this new method would return that. Hope that makes sense.
--Sean
