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

[Wilfred Mallawa <wilfred.mallawa@wdc.com>]

On Sat, 2026-03-14 at 07:39 -0700, Jakub Kicinski wrote:
> On Fri, 13 Mar 2026 14:16:10 +0100 Sabrina Dubroca wrote:
> > 2026-03-09, 15:48:36 +1000, Wilfred Mallawa wrote:
> > > From: Wilfred Mallawa <wilfred.mallawa@wdc.com>
> > > 
> > > Currently, for TLS 1.3, ktls does not support record zero padding
> > > [1].
> > > Record zero padding is used to allow the sender to hide the size
> > > of the
> > > traffic patterns from an observer. TLS is susceptible to a
> > > variety of traffic
> > > analysis attacks based on observing the length and timing of
> > > encrypted
> > > packets [2]. Upcoming Western Digital NVMe-TCP hardware
> > > controllers
> > > implement TLS 1.3. Which from a security perspective, can benefit
> > > from having
> > > record zero padding enabled to mitigate against traffic analysis
> > > attacks [2].
> > > 
> > > Thus, for TX, add support to appending a randomized number of
> > > zero padding
> > > bytes to end-of-record (EOR) records that are not full. The
> > > number of zero  
> > 
> > I don't think this is the right behavior. I expect that a user that
> > enables zero-padding would want _every_ record they send to be
> > padded,
> > and their payload is going to be split into however many records
> > that
> > requires. This could mean that data that would just fit in a record
> > will get split into one full + one very small record.
> > 
> > As it is, if I repeatedly call send with MSG_MORE to let ktls chunk
> > this for me, zero-padding has no effect. That doesn't seem right.
> > 
> > Does that make sense?
> 
> Or maybe you could refer to existing implementations of this feature
> in user space libs? The padding feature seems slightly nebulous, 
> I wasn't aware of anyone actually using it. Maybe I should ask...
> are you actually planning to use it, or are you checking a box?

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.

> 
> Second question - do we also need to support zero-byte records
> (entire
> record is padding) to prevent timing attacks?

That's a good point, although it is not needed, having it could benefit
in timing attacks. As RFC8446 [1] puts it, 
"This permits generation of plausibly sized cover traffic in contexts
where the presence or absence of activity may be sensitive."

I can look into that if we are going ahead with this series...

Regards,
Wilfred

[1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4