Re-sending this, new mail client sent with HTML...Sorry for the noise! On Fri, 2026-03-13 at 13:13 +0100, Sabrina Dubroca wrote: > Hi Wilfred, > Sorry for the delay, I'm juggling a few too many things at the > moment.
Hey Sabrina, No worries, thanks for the feedback on this series! > > 2026-03-09, 15:48:35 +1000, Wilfred Mallawa wrote: > > From: Wilfred Mallawa <[email protected]> > > > > Currently, for TLS 1.3, ktls does not support record zero padding > > [1]. > > to be precise: "on TX" (here, in the subject, and a few spots in the > rest of the series) > > > 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, this series adds support to adding randomized number > > of zero > > padding bytes to end-of-record (EOR) records that are not full. > > This > > feature is disabled by default and can be enabled by the new > > TLS_TX_RANDOM_PAD socket option. TLS_TX_RANDOM_PAD allows users to > > set an upper > > bound for the number of bytes to be used in zero padding, and can > > be set > > back to 0 to disable zero padding altogher. The number of zero > > padding bytes > > to append is determined by the remaining record room and the user > > specified > > upper bound (minimum of the two). That is > > rand([0, min(record_room, upper_bound)]). > > From an API point of view, I'm not sure TLS_TX_RANDOM_PAD (and with > only an upper bound) is what we want. Passing > {lower_bound,upper_bound} > via the setsockopt would be more flexible, allow to always pad if > userspace desires (maybe they're only sending very short records and > want to hide that with 1000B+ padding every time? no idea), and also > allow fixed-size padding if desired (by passing > lower_bound==upper_bound). I think this makes sense, and I can look into this, if we are going ahead with this series. > But I'm not involved in userspace libraries so I don't know. Our main use-case has been using record zero padding with NVMe oF TCP + TLS. Which means everything happens in the kernel. NVMe PDUs -> TLS Records -> TCP. So in that context, this approach made sense. > > I'm also worried about the (still WIP) 1.3 offload proposal. Are HW > implementations going to support this? Should we consider that as a > problem wrt transparency of HW offload in ktls? That's a good point, I had not considered the 1.3 offload proposal, it will likely need some driver level integration to enable this on supported devices... As of now this is exclusive to the SW driver. This series doesn't make that clear and will need to address that. i.e we can make setsockopt() complain if HW offload is enabled. > > > Also a selftest is added to test the usage of TLS_TX_RANDOM_PAD. > > However, it does not test for zero padding bytes as that is > > stripped in > > the ktls RX path. > > Couldn't you use "raw RX" type tests and parse_tls_records to check > the padding? Do you mean an RX without having keys installed? Similar to what we do for the record size limit tests? If so, the zero padding is still stripped in the kernel iirc. Regards, Wilfred
