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
