Hi Luke, LC1: Yes we will have tests that exercise the unsupported code paths with Java 17 in the CI. Updated
LC2.1 As Arnab said, the configuration takes precedence over the system property. We already have the same behavior today with ssl.cipher.suites and ssl.enabled.protocols which both have JVM system properties too. LC2.2: Right, I've added some more details in the compatibility section. Thanks, Mickael On Thu, Oct 15, 2026 at 4:32 PM Arnab nandy via dev <[email protected]> wrote: > > Hi Luke, Thanks for reviewing the KIP. Regarding LC1, that makes sense. > The tests can run on all supported Java versions rather than skipping the > unsupported case entirely. On Java 20 and later, they can verify that > configured named groups are applied. On earlier Java versions, a non-empty > ssl.named.groups can be tested to ensure that creating the SSL engine throws > an InvalidConfigurationException. Empty or unset configurations should > continue to work without calling SSLParameters.setNamedGroups(). I’ll update > the PR tests accordingly. Regarding LC2, my understanding is that a > non-empty ssl.named.groups is an explicit Kafka configuration and is applied > to each Kafka-created SSL engine through SSLParameters.setNamedGroups(). It > therefore takes precedence over the JVM-wide jdk.tls.namedGroups value for > those engines. When ssl.named.groups is empty or unset, Kafka does not call > setNamedGroups(), so the JVM system propertyor the provider defaults when > that property is absentcontinues to apply. I agree that this precedence > should be stated explicitly in the compatibility section. I don’t think Kafka > needs to reject or warn when both are configured, since the Kafka-specific > setting is presumably an intentional per-application override, but it would > be useful to document the behavior clearly. > Thanks and regardsArnab Nandy > > On Thursday, 15 October 2026 at 01:00:48 pm IST, Luke Chen > <[email protected]> wrote: > > Hi Mickael, > Thanks for the KIP!This is necessary to protect connections in kafka. > LC1: "These tests will be skipped when run on a JVM that does not support > named groups. The CI already runs with Java 25, so this will be effectively > tested."I'm wondering if we can run tests with all java versions, but expect > to fail when running on unsupported versions? If we only test java 25, we > can't test the unsupported java version with ConfigExceptions, right? > LC2: About the jvm "jdk.tls.namedGroups" system properties:LC2.1. What if > current users already set "jdk.tls.namedGroups=x25519" system properties, and > after this KIP, it also sets "ssl.named.groups=x448", then I think the jvm > system properties will be skipped, right? Do you think this will cause some > unexpected security problems? Maybe when setting "ssl.named.groups", we > should check if "jdk.tls.namedGroups" system properties are set or not?LC2.2. > In the compatibility section, I think we should add some explanations about > how we honor "ssl.named.groups" and "jdk.tls.namedGroups" when each is set or > not set. > > Thank you,Luke > On Sun, Oct 11, 2026 at 10:49 PM Arnab Nandy via dev <[email protected]> > wrote: > > Hi Mickael, > > Thanks, that clarifies both points. > > I’ll update PR #22865 so that ssl.named.groups follows the same behavior as > ssl.cipher.suites: when the configuration is empty or unset, Kafka will not > call SSLParameters.setNamedGroups() and the JVM/provider defaults will be > preserved. A non-empty value will be applied in the configured preference > order. > > The current PR will be more focused on the client and broker implementation, > and handle OAuth and Connect REST support in separate follow-up PRs under > KIP-1376. > > Also update the documentation and examples to use Java 27 and x25519_mlkem768. > > And sorry for this duplication on a separate thread. I'm using ASF Mailing > List first time so misjudged how it works, adding the link here for the > context of my reply. > > https://lists.apache.org/thread/olv28ft7m05obm01b8hj19mld2lzhc9d > > Thanks, > Arnab > > 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> > > > > Regards > Arnab Nandy > >
