On Mon, 2026-03-16 at 18:30 -0700, Jakub Kicinski wrote: > 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?
Ah right, I haven't seen any PoC/CVEs which could directly be addressed by zero padding. Wilfred
