On Sat, 2026-03-14 at 07:39 -0700, Jakub Kicinski wrote: > 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 <[email protected]> > > > > > > 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?
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. > > Second question - do we also need to support zero-byte records > (entire > record is padding) to prevent timing attacks? That's a good point, although it is not needed, having it could benefit in timing attacks. As RFC8446 [1] puts it, "This permits generation of plausibly sized cover traffic in contexts where the presence or absence of activity may be sensitive." I can look into that if we are going ahead with this series... Regards, Wilfred [1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4
