Hi Mickael and Paolo, Thanks for the clarifications. I’m working on PR #22865, which currently implements the client and broker portion through DefaultSslEngineFactory. The implementation uses reflection for SSLParameters.setNamedGroups() and does not attempt to validate named-group compatibility with the configured TLS version. I agree that this should remain the responsibility of the JVM and SSL provider, consistent with how cipher suites are handled.
I’ll also align the documentation with Java 27 and use x25519_mlkem768 in the examples. There are two points I’d like to understand: First, the JDK distinguishes an unset value from an empty named-groups array. An unset value preserves the provider defaults, while an explicitly empty array means that no named groups are enabled. The KIP currently describes the default as “Empty, the default JVM named groups are used,” which could make these two cases ambiguous. Would it make sense to define the behavior as follows? - Unset or null: use the JVM/provider defaults. - Explicitly empty list: disable named groups for that connection. - Non-empty list: apply the configured groups in preference order. Second, would it be acceptable to keep PR #22865 focused on clients and brokers, and implement the OAuth and Connect REST portions in separate follow-up PRs under the same KIP? This would keep each change smaller while still covering all the channels described by KIP-1376. Thanks, Arnab Thanks and regardsArnab Nandy On 2026/10/07 13:07:14 Mickael Maison wrote: > Hi Paolo, > > 1. No I'm not referring to this API. As per the javadoc, the > SSLParameters.setNamedGroups() API was added in Java 20. > From a quick search it wasn't part of a JEP, here is the CSR: > https://bugs.openjdk.org/browse/JDK-8291950 > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#setNamedGroups(java.lang.String[]) > > 2. Good catch, fixed > > 3. My understanding is that roadmap is only for Oracle. I don't want > to set expectations that other vendors will follow it or even backport > that feature. > > 4. "Drop" means they are ignored. So if you set ssl.protocol to > TLSv1.2 and a named group only available in TLSv1.3, the named group > will be ignored. > I propose to let the JVM handle it and possibly throw a TLS handshake > exception at runtime if the configuration is invalid. This is based on > these two reasons: > - it matches the behavior of ciphers > - checking the named groups and TLS version is likely to be brittle as > new names are added/removed and the exact behavior may depend on the > specific JVM > > Thanks, > Mickael > > > > On Wed, Oct 7, 2026 at 12:11 PM Paolo Patierno <[email protected]> wrote: > > > > Hi Mickael, > > thanks for opening the KIP and starting such discussion. > > > > > Named groups are how the JVM describes TLS key exchange schemes. APIs to > > use named groups have been added in Java 20. > > Are you referring to KEM API? Because JEP-452 <https://openjdk.org/jeps/452> > > was done as part of Java 21 not 20. > > > > > This JEP was initially delivered in Java 26 > > Even in this case JEP-527 <https://openjdk.org/jeps/527> was delivered as > > part of Java 27 not 26. > > > > > It's being backported by several implementations to earlier Java versions. > > You can add a reference to the roadmap > > <https://www.java.com/en/jre-jdk-cryptoroadmap.html> or you can find more > > details on this link about the Oracle plan > > https://blogs.oracle.com/java/post-quantum-cryptography-in-long-term-support-jdk-releases > > so > > that readers can have an idea about the older Java versions which are going > > to get it (first one will be Java 25 at the end of October 2026). > > > > > The TLS version (set via ssl.protocol) gates what named groups are valid > > and automatically drops entries not compatible (like for ciphers). > > What does exactly mean "drop" here? If I set TLS 1.2 for example but then > > in the named groups I add "X25519MLKEM768", does Kafka refuse the > > configuration? Or it leaves to the JVM during the TLS handshake? (If you > > have x25519 in the list it should fall back. It works for TLS 1.3 but need > > to be confirmed for 1.2). > > > > Thanks, > > Paolo > > > > On Tue, 6 Oct 2026 at 12:14, Mickael Maison <[email protected]> > > wrote: > > > > > Hi, > > > > > > I'd like to start a discussion about KIP-1376 which proposes adding > > > support for TLS named groups: > > > https://cwiki.apache.org/confluence/x/dJXwGg > > > > > > Thanks, > > > Mickael > > > > > > > > > -- > > Paolo Patierno > > > > *Senior Principal Software Engineer @ IBM**CNCF Ambassador* > > > > Twitter : @ppatierno <http://twitter.com/ppatierno> > > Linkedin : paolopatierno <http://it.linkedin.com/in/paolopatierno> > > GitHub : ppatierno <https://github.com/ppatierno> >
