On Tue, 2026-03-17 at 01:53 +0000, Wilfred Mallawa wrote: > 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?
In 2014 a group at UC Berkeley used HTTPS traffic analysis to identify: "individual pages in the same web-site with 90% accuracy, exposing personal details including medical conditions, financial and legal affairs and sexual orientation." They used machine learning to help and that was over 10 years ago. So I suspect modern day machine learning would make this even easier to do today. Obviously that is HTTP traffic, which is different to the NVMe-TCP traffic this series is targeting, but it does still seem like a real concern. They talk about a range of defences in the paper, with tradeoffs between all of them. But the linear defence seems like the one that is applicable here: "linear defense pads all packet sizes up to multiples of 128" The linear defence seems to reduce the Pan attack from 60% to around 25% and the BoG attack from 90% to around 60%. On top of that the "Burst defense offers greater protection, operating between the TCP layer and application layer to pad contiguous bursts of traffic up to predefined thresholds uniquely determined for each website" Which to me sounds like the random padding proposed in this series would provide more protection then the basic linear padding used in the paper. To me analysing TLS traffic does seem like a plausible threat and something that randomised padding would help with. Leaving it up to userspace to decide based on their threat model seems like a good approach as well. 1: https://secml.cs.berkeley.edu/pets2014/ Alistair > > Ah right, I haven't seen any PoC/CVEs which could directly be > addressed > by zero padding. > > Wilfred
