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

[Jakub Kicinski]

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@xxxxxxx>
> > 
> > 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?

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