Hi Giannis, Anton,
Thanks for the detailed reviews. I've updated the FIP to address all
points raised. You can find the summary of changes below and a diff
attached for your convenience.
---
Zero-copy (Giannis Q1, Anton)
This was a big oversight on my part; I apologize.
Thanks for unveiling this.
You are both correct. TLS and sendfile are mutually exclusive: SslHandler
requires bytes in JVM-managed memory before encryption, which is
incompatible with FileChannel.transferTo(). On TLS-enabled listeners, log
fetch responses are copied into a buffer in the JVM before encryption.
Plaintext listeners are unaffected. This is the same trade-off Apache Kafka
makes with SSL.
I've added a "Performance trade-off: zero-copy" subsection to the FIP that
calls this out explicitly, so operators can account for it in capacity
planning. kTLS is now explicitly listed as Out of Scope rather than left
implied.
---
Short-lived credentials (Giannis Q2)
The design does not assume short-lived credentials. Hot-reload is entirely
opt-in: setting security.ssl.reload.interval=0 disables polling, and the
system works correctly with static long-lived certificates. Rotation in that
model is handled with an explicit rolling restart, exactly as any other
config change today. The 5-minute default targets cloud-native deployments;
if files never change, reload is a no-op.
I've added an explicit note on static/long-lived certs to the hot-reload
section.
---
Non-goals (Anton)
Added a dedicated Non-Goals section covering ZooKeeper connection security,
remote storage encryption, and data at rest. The FIP now states explicitly
that enabling RPC TLS does not imply end-to-end cluster encryption.
---
Configuration validation (Anton)
Expanded to a fail-fast startup validation table covering the cases you
listed.
---
Metrics (Anton)
The two metrics you flagged are promoted to v1:
- tls.handshake.failures (counter, per listener): matches
Kafka's failed-authentication-total. Handshake failures are below
the normal RPC error path; logs-only is effectively invisible in
production.
- tls.certificate.days.to.expiry (gauge, per listener): fills the
gap Kafka has never closed, enabling expiry alerting before it
becomes a handshake failure.
On the reactive self-healer: I agree the interval-only model is
simpler and closer to what Kafka ships. However, the reactive trigger
provides a concrete safety guarantee that the interval-only model
cannot: a certificate renewed just after a poll is adopted on the
next connection attempt rather than after up to reload.interval. For
short-lived certs (e.g., 1-hour SPIFFE SVIDs) with a 5-minute poll
interval, that window matters. The reactive logic is also isolated and
safe by construction: rate-limited, never swaps in a broken context,
and does not retry the triggering connection. I'd like to keep it in
v1. Happy to discuss further on the list if you feel strongly about
deferring it.
---
SslPrincipalMapper (Anton)
Added explicit fail-fast behaviour: unsupported rule grammar causes the
server to refuse to start, not fail at authentication time. This is the
right place — the rules are static config, validation is cheap (regex
compile), and startup failure is far more diagnosable than a per-
connection authorization failure that looks like an ACL misconfiguration.
The validation table in the FIP now has an eighth row for this.
---
Let me know if
anything needs further discussion.
Best,
Lorenzo
On Fri, Jun 19, 2026 at 6:58 AM Giannis Polyzos <[email protected]>
wrote:
> Hi Lorenzo,
> thank you for the really nice and detailed FIP.
>
> May I suggest attaching the link to the proposal?
>
> https://cwiki.apache.org/confluence/display/FLUSS/FIP-29%3A+%28m%29TLS+Support
>
> Overall the proposal looks great and looks solid to me.
> Two questions I have just for clarity:
> 1. Netty’s SslHandler can’t encrypt a FileRegion.. Does this mean that
> TLS enables clients will lose zero-copy? Or is there a workaround for this?
> If not I think maybe it would be good to explicitly mention this in the
> proposal so users are aware of this trade-off
>
> 2. Does the design assume always short-lived credentials?
>
> Overall it looks good to me and it’s a +1 on my side.
>
> Best,
> Giannis
>
> On Fri, 12 Jun 2026 at 5:44 PM, Lorenzo Affetti via dev <
> [email protected]> wrote:
>
>> Hello community!
>>
>> I would like to start a discussion about FIP-29: (m)TLS support.
>>
>> Here is the motivation:
>>
>> All Fluss RPC traffic — between clients and servers, and between servers —
>> currently travels over the network *in plaintext*.
>>
>> This has two consequences:
>>
>> 1. *Confidentiality.* Table data, metadata, and even the credentials
>> exchanged by the existing application-layer authentication are visible
>> to
>> anyone able to observe the network. In shared, cloud, or multi-tenant
>> deployments this is unacceptable.
>> 2. *Strong client authentication.* Fluss has a pluggable authentication
>> framework, but it has no certificate-based mechanism. Operators who
>> standardize on PKI / mutual TLS for service-to-service identity (a very
>> common requirement) cannot integrate Fluss.
>>
>> This FIP adds:
>>
>> - *TLS transport encryption* for the Netty RPC layer, enabled per
>> server
>> listener and on the client.
>> - *Mutual TLS (mTLS) authentication*, where the server derives the
>> authenticated FlussPrincipal from the client's X.509 certificate,
>> integrated into the existing authentication/authorization pipeline.
>>
>>
>> Eager to hear about your thoughts!
>>
>> --
>> Lorenzo Affetti
>> Team Leader of Stream Storage
>> [email protected]
>> www.ververica.com
>> ------------------------------
>>
>> <https://www.ververica.com/>
>> Ververica GmbH | Herzogspitalstrasse 24 | 80331 München | Germany
>> <https://www.google.com/maps/search/Herzogspitalstrasse+24+%7C+80331+M%C3%BCnchen+%7C+Germany?entry=gmail&source=g>
>>
>> Follow us:
>> <https://www.linkedin.com/company/ververica/posts/?feedView=all>
>> <https://www.youtube.com/@ververica>
>> <https://open.spotify.com/show/2XME9h8iBOyr6YupqM99ir?si=87b064644add42a1
>> >Available
>> on: <https://aws.amazon.com/marketplace/pp/prodview-luvmqd6leha4i>
>> <
>> https://marketplace.microsoft.com/en-us/product/saas/ververica.vvc_managed?tab=Overview
>> >
>>
>> Pflichtangaben/Mandatory Information
>> <https://www.ververica.com/mandatory-information>
>>
>
--
Lorenzo Affetti
Senior Software Engineer @ Flink Team
Ververica <http://www.ververica.com>
