public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Wilfred Mallawa <wilfred.opensource@gmail.com>
To: John Fastabend <john.fastabend@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Sabrina Dubroca <sd@queasysnail.net>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>
Cc: netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	Alistair Francis <alistair.francis@wdc.com>,
	Damien Le'Moal <dlemoal@kernel.org>,
	Wilfred Mallawa <wilfred.mallawa@wdc.com>
Subject: [RFC net-next 0/3] tls_sw: add tx record zero padding
Date: Mon,  9 Mar 2026 15:48:35 +1000	[thread overview]
Message-ID: <20260309054837.2299732-2-wilfred.opensource@gmail.com> (raw)

From: Wilfred Mallawa <wilfred.mallawa@wdc.com>

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, 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)]).

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. 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

 Documentation/networking/tls.rst  | 21 +++++++++
 include/net/tls.h                 |  1 +
 include/uapi/linux/tls.h          |  2 +
 net/tls/tls.h                     |  6 ++-
 net/tls/tls_main.c                | 72 +++++++++++++++++++++++++++++++
 net/tls/tls_sw.c                  | 58 ++++++++++++++++++++-----
 tools/testing/selftests/net/tls.c | 45 +++++++++++++++++++
 7 files changed, 194 insertions(+), 11 deletions(-)

-- 
2.53.0


             reply	other threads:[~2026-03-09  5:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09  5:48 Wilfred Mallawa [this message]
2026-03-09  5:48 ` [RFC net-next 1/3] net/tls_sw: support randomized zero padding Wilfred Mallawa
2026-03-13 13:16   ` Sabrina Dubroca
2026-03-14 14:39     ` Jakub Kicinski
2026-03-17  0:53       ` Wilfred Mallawa
2026-03-17  1:03         ` Jakub Kicinski
2026-03-17  1:21           ` Wilfred Mallawa
2026-03-17  1:30             ` Jakub Kicinski
2026-03-17  1:53               ` Wilfred Mallawa
2026-03-19  1:35                 ` Alistair Francis
2026-03-17  9:19           ` Sabrina Dubroca
2026-03-17  0:20     ` Wilfred Mallawa
2026-03-09  5:48 ` [RFC net-next 2/3] net/tls: add randomized zero padding socket option Wilfred Mallawa
2026-03-09  5:48 ` [RFC net-next 3/3] selftest: tls: add tls record zero pad test Wilfred Mallawa
2026-03-13 12:13 ` [RFC net-next 0/3] tls_sw: add tx record zero padding Sabrina Dubroca
2026-03-17  0:59   ` Wilfred Mallawa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260309054837.2299732-2-wilfred.opensource@gmail.com \
    --to=wilfred.opensource@gmail.com \
    --cc=alistair.francis@wdc.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dlemoal@kernel.org \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sd@queasysnail.net \
    --cc=skhan@linuxfoundation.org \
    --cc=wilfred.mallawa@wdc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox