Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 17 Mar 2026 01:21:12 +0000 Wilfred Mallawa wrote:
> On Mon, 2026-03-16 at 18:03 -0700, Jakub Kicinski wrote:
> > On Tue, 17 Mar 2026 00:53:07 +0000 Wilfred Mallawa wrote:  
>  [...]  
> > > 
> > > For upcoming WD hardware, we were planning on informing users to
> > > use
> > > this feature if an extra layer of security can benefit their
> > > particular
> > > configuration. But to answer your question, I think this falls more
> > > into the "checking a box"...
> > > 
> > > I'm happy to drop this series if there's not much added value from
> > > having this as an available option for users.  
> > 
> > I'm not much of a security person, and maybe Sabrina will disagree
> > but I feel like it's going to be hard for us to design this feature
> > in a sensible way if we don't know at least one potential attack :S  
> 
> Traffic analysis is the attack vector we are trying to mitigate against
> with zero padding, which TLS is susceptible to [1]. I think the hard
> part is deciding the padding policy and balancing it such that we have
> sensible performance.
> 
> This series adds random padding to records with room, a stronger policy
> I think would be to pad all records to max record size length. But that
> adds a much higher performance overhead. For context, when testing NVMe
> TCP+TLS with 4K writes with a record size limit of 4k, we observed a
> 50% reduction in IOPs on the fixed max record pad policy as opposed to
> the random padding policy from this series.

Sorry, I realized when i hit "send" that I phrased my previous message
poorly. When I say "potential" I mean someone actually presenting a PoC
and a CVE is issued for it. Have we seen any of those?