[
https://issues.apache.org/jira/browse/KAFKA-20728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097586#comment-18097586
]
Andrew Schofield commented on KAFKA-20728:
------------------------------------------
Adding PQC to Apache Kafka is important but we are going to need a KIP for it
to discuss the approach and agree any external changes.
> 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
> 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)
