Hi Wilfred, Sorry for the delay, I'm juggling a few too many things at the moment.
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). But I'm not involved in userspace libraries so I don't know. 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? > 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? > Additional testing done on a linux NVMe Target with > TLS by issuing an FIO workload to the target and asserting that the target > kernel sees and strips the zero padding attached. > > [1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4l > [2] https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.3 > > Wilfred Mallawa (3): > net/tls_sw: support randomized zero padding > net/tls: add randomized zero padding socket option > selftest: tls: add tls record zero pad test -- Sabrina
