[jira] [Commented] (KAFKA-20728) Post-Quantum Cryptography (PQC) TLS Readiness: Add setNamedGroups() and ssl.named.groups configuration (ref: CAMEL-23154)

["Mickael Maison (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-20728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123724#comment-18123724 ] 

Mickael Maison commented on KAFKA-20728:
----------------------------------------

[~arnabnandy7] I've kicked off the KIP discussion on the dev list: https://lists.apache.org/thread/wwlb3yl9hnrcflm8h33g7jmqv7zkw6md

My recommendation would be to wait till we get feedback on the KIP before touching the PR again. If the KIP is accepted, then we could deliver it in several pieces, with your PR for clients/servers and follow-up PRs for other components.

> Post-Quantum Cryptography (PQC) TLS Readiness: Add setNamedGroups() and ssl.named.groups configuration (ref: CAMEL-23154)
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-20728
>                 URL: https://issues.apache.org/jira/browse/KAFKA-20728
>             Project: Kafka
>          Issue Type: Improvement
>          Components: clients, core, security
>            Reporter: Netan Mangal
>            Assignee: Arnab Nandy
>            Priority: Major
>              Labels: needs-kip
>
> h2. Context: Regulatory Deadline
> France's ANSSI will *stop certifying security products without post-quantum cryptography starting in 2027* - the first hard regulatory deadline globally.
> Source: [The Quantum Threat to Encryption Is Coming. France Just Set a 2027 Deadline|https://gizmodo.com/the-quantum-threat-to-encryption-is-coming-france-just-set-a-2027-deadline-2000773650]
> Additional mandates:
> * *US NSA CNSA 2.0:* PQC required for national security systems by 2027
> * *NIST IR 8547:* Classical asymmetric cryptography deprecated by 2030, disallowed by 2035
> * *EU:* Critical infrastructure PQC transition targeted by 2030
> Kafka is deployed across government, defense, financial, and healthcare environments worldwide. This ticket proposes adding PQC TLS readiness to Apache Kafka.
> h2. The Concrete Gap
> Apache Camel fixed this identical gap in [CAMEL-23154|https://issues.apache.org/jira/browse/CAMEL-23154] (resolved in Camel 4.19.0, April 2026). The fix: add {{SSLParameters.setNamedGroups()}} support so that PQC hybrid TLS key exchange algorithms like {{X25519MLKEM768}} (defined in [JEP 527|https://openjdk.org/jeps/527]) can be negotiated.
> *Kafka has the same gap:*
> * Kafka's {{SslFactory}} / {{SslEngineBuilder}} does *not* call {{SSLParameters.setNamedGroups()}}
> * There is *no* {{ssl.named.groups}} broker or client configuration parameter
> * Even on JDK 24+ (which ships ML-KEM via JCA), Kafka cannot negotiate PQC key exchange because the named groups are never set
> * The JVM system property {{jdk.tls.namedGroups}} could work as a workaround but is undocumented and untested by the Kafka project
> h2. Proposed Changes
> h3. Phase 1: Enable PQC Key Exchange
> * Add {{SSLParameters.setNamedGroups()}} call in {{SslEngineBuilder}} (analogous to [CAMEL-23154|https://issues.apache.org/jira/browse/CAMEL-23154])
> * Add {{ssl.named.groups}} broker and client configuration parameter
> * Default value: let JVM choose (preserves backward compatibility)
> * Example config: {{ssl.named.groups=X25519MLKEM768,X25519,secp256r1,secp384r1}}
> h3. Phase 2: Validation & Documentation
> * Validate broker-to-broker and client-to-broker TLS 1.3 with {{X25519MLKEM768}} on JDK 24+
> * Document PQC TLS configuration
> * Add integration tests verifying hybrid PQC key exchange
> * Measure performance impact of PQC handshakes
> h3. Phase 3: JDK 27 Readiness (September 2026)
> * [JEP 527|https://openjdk.org/jeps/527] enables {{X25519MLKEM768}} *by default* on JDK 27
> * Ensure Kafka's TLS stack does not inadvertently block this default
> * Test and officially support JDK 24+
> h2. Why This Matters Now
> The "harvest now, decrypt later" threat means adversaries are already capturing encrypted Kafka traffic with the intent to decrypt it when quantum computers arrive. For organizations handling classified, financial, or health data, PQC TLS is an immediate risk, not a future concern.
> Confluent Cloud has a [PQC roadmap|https://www.confluent.io/blog/confluent-cloud-post-quantum-cryptography-roadmap/] targeting 2030, but the open-source Apache Kafka project has zero PQC tracking or work. This leaves the vast majority of Kafka deployments (self-hosted, on-prem, non-Confluent) without a migration path.
> h2. NIST Standards Reference
> ||Standard||Algorithm||Purpose||
> |FIPS 203|ML-KEM (Kyber)|Key Encapsulation Mechanism|
> |FIPS 204|ML-DSA (Dilithium)|Digital Signatures|
> |FIPS 205|SLH-DSA (SPHINCS+)|Hash-based Signatures|
> h2. References
> * [France ANSSI 2027 Deadline|https://gizmodo.com/the-quantum-threat-to-encryption-is-coming-france-just-set-a-2027-deadline-2000773650]
> * [Apache Camel CAMEL-23154 (same fix)|https://issues.apache.org/jira/browse/CAMEL-23154]
> * [JEP 527 — Post-Quantum Key Exchange for TLS 1.3|https://openjdk.org/jeps/527]
> * [NIST FIPS 203 (ML-KEM)|https://csrc.nist.gov/pubs/fips/203/final]
> * [NIST IR 8547 — Transition to PQC|https://csrc.nist.gov/pubs/ir/8547/final]
> * [Confluent Cloud PQC Roadmap (Cloud-only)|https://www.confluent.io/blog/confluent-cloud-post-quantum-cryptography-roadmap/]
> * [Bouncy Castle PQC|https://www.bouncycastle.org/resources/latest-nist-pqc-standards-and-more-bouncy-castle-java-1-79/]
> I'm happy to raise the PR for this issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)