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? Second question - do we also need to support zero-byte records (entire record is padding) to prevent timing attacks?
