Re: [RFC net-next 0/3] tls_sw: add tx record zero padding

[Sabrina Dubroca <sd@queasysnail.net>]

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 <wilfred.mallawa@wdc.com>
> 
> 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