Hi Bernd, Thanks for relaying this and for the ISV perspective. On Fri, Jul 17, 2026, Bernd <ecki@ zusammenkunft. net> wrote: > Maybe a compromise would be that getting the parameters must reflect > removed groups (but I am not sure
Hi Bernd,
Thanks for relaying this and for the ISV perspective.
On Fri, Jul 17, 2026, Bernd <[email protected]> wrote:
> Maybe a compromise would be that getting the parameters must reflect
> removed groups (but I am not sure this is a compatible Change, maybe
> only allowing/recommending the thing to return the effective set, so
> client code can validate but current versions are still compliant?
I tested exactly this premise, since my original note was imprecise
about which object the post-handshake read was made on. To rule out
the trivial explanation (re-reading the application's own retained
SSLParameters instance), I ran a stock-JSSE TLS 1.3 client with
setNamedGroups({"MLKEM768","x25519"}) against a PQ-capable endpoint
(https://www.google.com/url?q=http://pq.cloudflareresearch.com:443&source=gmail&ust=1784612566975000&sa=E)
and, after the handshake completed,
called getSSLParameters() fresh on the connected socket.
Result, identical on JDK 26.0.1 (26.0.1+8-34) and JDK 27 EA
(27-ea+30-2302):
HANDSHAKE: SUCCESS, protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384
RETAINED params.getNamedGroups() = MLKEM768,x25519
FRESH socket.getSSLParameters().getNamedGroups() = MLKEM768,x25519
sameObject=false (fresh call returns a new instance every time)
The debug trace confirms MLKEM768 was dropped from the ClientHello
(JDK 26: "Ignore unspecified named group"; JDK 27 EA: "Ignore
inactive or disabled named group") and that the ServerHello key_share
negotiated x25519. So even the fresh, provider-constructed
SSLParameters instance reports the requested set, not the effective
one. Your "must reflect the effective set" variant would therefore be
a behavior change relative to both 26.0.1 GA and the current 27 EA
builds; the weaker "allow/recommend" variant would at least give
client code a supported validation path going forward.
Source and verbatim evidence, including the raw ssl:handshake traces:
https://www.google.com/url?q=https://github.com/Arpan0995/jdk-tls-namedgroup-silent-drop&source=gmail&ust=1784612566976000&sa=E
(src/FreshVsRetained.java, results/probe3-fresh-vs-retained.md)
> Definitely needed. Independent of PQC and named groups a listener
> providing handshake details (and also offered negotiation details)
> would be very (for Client and Server sockets).
Agreed, and your auditing use case matches what I found: enumerating
every public method on SSLSession, ExtendedSSLSession, SSLParameters,
SSLSocket and SSLEngine mentioning group/kex/KEM turns up only
SSLParameters.get/setNamedGroups; SSLSession.getValueNames() is
empty, and TLS 1.3 cipher suites are key-exchange-agnostic, so
getCipherSuite() discloses nothing. Today the only observation
channels are parsing -Djavax.net.debug output or reflection into
sun.security.ssl. Even a minimal read-only accessor for the
negotiated group (e.g. on ExtendedSSLSession) would cover the
detection case; a handshake-details listener like you describe would
additionally cover offered-vs-negotiated auditing before an algorithm
is disabled.
Regards,
Arpan Sharma
On Fri, Jul 17, 2026 at 3:54 PM Bernd <[email protected]> wrote:
>
> >From Arpan Sharma: > 1. Is the "providers should ignore unknown named group scheme names" contract > still considered correct, now that named groups are a security-policy > parameter (post-JEP-527) rather than a performance hint? Maybe
> From Arpan Sharma:
> > 1. Is the "providers should ignore unknown named group scheme names" contract
> > still considered correct, now that named groups are a security-policy
> > parameter (post-JEP-527) rather than a performance hint?
>
> Maybe a compromise would be that getting the parameters must reflect removed groups (but I am not sure this is a compatible Change, maybe only allowing/recommending the thing to return the effective set, so client code can validate but current versions are still compliant?
> > 3. Is there interest in exposing the negotiated named group through a public API
>
> (Let me give my user Feedback from the view Point of ISV with Enterprise Customers battling with hundreds of possible Legacy Software Communication Partners):
>
> Definitely needed. Independent of PQC and named groups a listener providing handshake details (and also offered negotiation details) would be very (for Client and Server sockets). For example before we disable a certain algorithm (which happens to be the negotiated one) the Software should be able to tell if others are offered. And also auditing the used parameters without relying on net debug logs would be good. (At the moment you have to poke into custom log handlers or reflection).
>
> Gruß
> Bernd
>
> --
> https://bernd.eckenfels.net
>
