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?
