On Mon, 2026-03-16 at 18:03 -0700, Jakub Kicinski wrote: > On Tue, 17 Mar 2026 00:53:07 +0000 Wilfred Mallawa wrote: > > > 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. > > 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. Wilfred [1] https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.3
