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

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

[Wilfred Mallawa]

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

[RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Wilfred Mallawa]

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

For TLS 1.3, zero padding is added after the content type byte, as such,
if the record in context meets the above conditions for zero padding,
attach a zero padding buffer to the content type byte before a record is
encrypted. The padding buffer is freed when the record is freed.

By default, record zero padding is disabled, and userspace may enable it
by using the setsockopt TLS_TX_RANDOM_PAD option.

[1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4l
[2] https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.3

Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
---
 include/net/tls.h  |  1 +
 net/tls/tls.h      |  6 ++++-
 net/tls/tls_main.c |  2 ++
 net/tls/tls_sw.c   | 58 ++++++++++++++++++++++++++++++++++++++--------
 4 files changed, 56 insertions(+), 11 deletions(-)

diff --git a/include/net/tls.h b/include/net/tls.h
index ebd2550280ae..1feef72cc339 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -229,6 +229,7 @@ struct tls_context {
 	u8 zerocopy_sendfile:1;
 	u8 rx_no_pad:1;
 	u16 tx_max_payload_len;
+	u16 tx_record_zero_pad;
 
 	int (*push_pending_record)(struct sock *sk, int flags);
 	void (*sk_write_space)(struct sock *sk);
diff --git a/net/tls/tls.h b/net/tls/tls.h
index e8f81a006520..3a86eb145332 100644
--- a/net/tls/tls.h
+++ b/net/tls/tls.h
@@ -121,8 +121,12 @@ struct tls_rec {
 	/* AAD | msg_encrypted.sg.data (data contains overhead for hdr & iv & tag) */
 	struct scatterlist sg_aead_out[2];
 
+	/* TLS 1.3 record zero padding */
+	char *zero_padding;
+	u16 zero_padding_len;
+
 	char content_type;
-	struct scatterlist sg_content_type;
+	struct scatterlist sg_content_trail[2];
 
 	struct sock *sk;
 
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index fd39acf41a61..b0702effbc26 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -1076,6 +1076,8 @@ static int tls_init(struct sock *sk)
 	ctx->tx_conf = TLS_BASE;
 	ctx->rx_conf = TLS_BASE;
 	ctx->tx_max_payload_len = TLS_MAX_PAYLOAD_SIZE;
+	/* TX record zero padding is disabled by default */
+	ctx->tx_record_zero_pad = 0;
 	update_sk_prot(sk, ctx);
 out:
 	write_unlock_bh(&sk->sk_callback_lock);
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index a656ce235758..84b167607e1f 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -389,6 +389,7 @@ static void tls_free_rec(struct sock *sk, struct tls_rec *rec)
 {
 	sk_msg_free(sk, &rec->msg_encrypted);
 	sk_msg_free(sk, &rec->msg_plaintext);
+	kfree(rec->zero_padding);
 	kfree(rec);
 }
 
@@ -430,6 +431,7 @@ int tls_tx_records(struct sock *sk, int flags)
 		 */
 		list_del(&rec->list);
 		sk_msg_free(sk, &rec->msg_plaintext);
+		kfree(rec->zero_padding);
 		kfree(rec);
 	}
 
@@ -450,6 +452,7 @@ int tls_tx_records(struct sock *sk, int flags)
 
 			list_del(&rec->list);
 			sk_msg_free(sk, &rec->msg_plaintext);
+			kfree(rec->zero_padding);
 			kfree(rec);
 		} else {
 			break;
@@ -779,12 +782,29 @@ static int tls_push_record(struct sock *sk, int flags,
 	sk_msg_iter_var_prev(i);
 
 	rec->content_type = record_type;
+
 	if (prot->version == TLS_1_3_VERSION) {
-		/* Add content type to end of message.  No padding added */
-		sg_set_buf(&rec->sg_content_type, &rec->content_type, 1);
-		sg_mark_end(&rec->sg_content_type);
+		/*
+		 * Add content type to end of message with zero padding
+		 * if available.
+		 */
+		sg_init_table(rec->sg_content_trail, 2);
+		sg_set_buf(&rec->sg_content_trail[0], &rec->content_type, 1);
+		if (rec->zero_padding_len) {
+			rec->zero_padding = kzalloc(rec->zero_padding_len,
+						    sk->sk_allocation);
+			if (!rec->zero_padding)
+				return -ENOMEM;
+
+			sg_set_buf(&rec->sg_content_trail[1],
+				   rec->zero_padding, rec->zero_padding_len);
+			sg_mark_end(&rec->sg_content_trail[1]);
+		} else {
+			sg_mark_end(&rec->sg_content_trail[0]);
+		}
+
 		sg_chain(msg_pl->sg.data, msg_pl->sg.end + 1,
-			 &rec->sg_content_type);
+			 rec->sg_content_trail);
 	} else {
 		sg_mark_end(sk_msg_elem(msg_pl, i));
 	}
@@ -805,19 +825,21 @@ static int tls_push_record(struct sock *sk, int flags,
 	i = msg_en->sg.start;
 	sg_chain(rec->sg_aead_out, 2, &msg_en->sg.data[i]);
 
-	tls_make_aad(rec->aad_space, msg_pl->sg.size + prot->tail_size,
-		     tls_ctx->tx.rec_seq, record_type, prot);
+	tls_make_aad(rec->aad_space, msg_pl->sg.size + prot->tail_size +
+		     rec->zero_padding_len, tls_ctx->tx.rec_seq,
+		     record_type, prot);
 
 	tls_fill_prepend(tls_ctx,
 			 page_address(sg_page(&msg_en->sg.data[i])) +
 			 msg_en->sg.data[i].offset,
-			 msg_pl->sg.size + prot->tail_size,
-			 record_type);
+			 msg_pl->sg.size + prot->tail_size +
+			 rec->zero_padding_len, record_type);
 
 	tls_ctx->pending_open_record_frags = false;
 
 	rc = tls_do_encryption(sk, tls_ctx, ctx, req,
-			       msg_pl->sg.size + prot->tail_size, i);
+			       msg_pl->sg.size + prot->tail_size +
+			       rec->zero_padding_len, i);
 	if (rc < 0) {
 		if (rc != -EINPROGRESS) {
 			tls_err_abort(sk, -EBADMSG);
@@ -1033,6 +1055,8 @@ static int tls_sw_sendmsg_locked(struct sock *sk, struct msghdr *msg,
 	unsigned char record_type = TLS_RECORD_TYPE_DATA;
 	bool is_kvec = iov_iter_is_kvec(&msg->msg_iter);
 	bool eor = !(msg->msg_flags & MSG_MORE);
+	bool tls_13 = (prot->version == TLS_1_3_VERSION);
+	bool rec_zero_pad = eor && tls_13 && tls_ctx->tx_record_zero_pad;
 	size_t try_to_copy;
 	ssize_t copied = 0;
 	struct sk_msg *msg_pl, *msg_en;
@@ -1043,6 +1067,7 @@ static int tls_sw_sendmsg_locked(struct sock *sk, struct msghdr *msg,
 	int record_room;
 	int num_zc = 0;
 	int orig_size;
+	int max_zero_pad_len, zero_pad_len = 0;
 	int ret = 0;
 
 	if (!eor && (msg->msg_flags & MSG_EOR))
@@ -1085,8 +1110,19 @@ static int tls_sw_sendmsg_locked(struct sock *sk, struct msghdr *msg,
 			full_record = true;
 		}
 
+		if (rec_zero_pad && !full_record)
+			zero_pad_len = record_room - try_to_copy;
+
+		if (zero_pad_len > prot->tail_size) {
+			max_zero_pad_len = min(zero_pad_len,
+					       tls_ctx->tx_record_zero_pad);
+			zero_pad_len =
+				get_random_u32_inclusive(0, max_zero_pad_len);
+			rec->zero_padding_len = zero_pad_len;
+		}
+
 		required_size = msg_pl->sg.size + try_to_copy +
-				prot->overhead_size;
+				prot->overhead_size + rec->zero_padding_len;
 
 		if (!sk_stream_memory_free(sk))
 			goto wait_for_sndbuf;
@@ -2555,6 +2591,7 @@ void tls_sw_release_resources_tx(struct sock *sk)
 				       struct tls_rec, list);
 		list_del(&rec->list);
 		sk_msg_free(sk, &rec->msg_plaintext);
+		kfree(rec->zero_padding);
 		kfree(rec);
 	}
 
@@ -2562,6 +2599,7 @@ void tls_sw_release_resources_tx(struct sock *sk)
 		list_del(&rec->list);
 		sk_msg_free(sk, &rec->msg_encrypted);
 		sk_msg_free(sk, &rec->msg_plaintext);
+		kfree(rec->zero_padding);
 		kfree(rec);
 	}
 
-- 
2.53.0

[RFC net-next 2/3] net/tls: add randomized zero padding socket option

[Wilfred Mallawa]

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

Add a new TLS_TX_RANDOM_PAD ktls socket option that allows userspace to
enable and specify an upperbound for randomized record zero padding
in TLS 1.3. When this value is set and non-zero, ktls will append a
randomized amount of [0, min(record_room, upper_bound)] bytes to records
that are end-of-record (EOR) and aren't full. This can be set back to zero
to disable appending zero padding. By default, no record zero padding is added.

The number of zero padding bytes is randomised primarilly to reduce some of
the throughput overhead of using a fixed zero padding amount up to the
record size limit.

[1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4l
[2] https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.3

Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
---
 Documentation/networking/tls.rst | 21 ++++++++++
 include/uapi/linux/tls.h         |  2 +
 net/tls/tls_main.c               | 70 ++++++++++++++++++++++++++++++++
 3 files changed, 93 insertions(+)

diff --git a/Documentation/networking/tls.rst b/Documentation/networking/tls.rst
index 980c442d7161..e112a68a9bfb 100644
--- a/Documentation/networking/tls.rst
+++ b/Documentation/networking/tls.rst
@@ -300,6 +300,27 @@ extra byte used by the ContentType field.
 
 [1] https://datatracker.ietf.org/doc/html/rfc8449
 
+TLS_TX_RANDOM_PAD
+~~~~~~~~~~~~~~~~~
+
+Enable and set the limit for randomized zero padding [1] of outgoing
+TLS records.
+
+When enabled, TLS records that are not full and are end of record (EOR)
+will be padded with a randomly chosen amount of zero padding up to the remaining
+record capacity or the limit provided by this option (smaller of the two).
+Randomized zero padding can reduce information leakage via observable TLS
+record lengths and mitigates traffic analysis based on message size.
+
+Padding never exceeds the protocol maximum record size and full-sized records
+are unchanged.
+
+This increases bandwidth usage and may add CPU overhead due to padding
+generation and larger encryption operations. For workloads with small records,
+the bandwidth overhead may be significant.
+
+[1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4
+
 Statistics
 ==========
 
diff --git a/include/uapi/linux/tls.h b/include/uapi/linux/tls.h
index b8b9c42f848c..42a318cb5eb8 100644
--- a/include/uapi/linux/tls.h
+++ b/include/uapi/linux/tls.h
@@ -42,6 +42,7 @@
 #define TLS_TX_ZEROCOPY_RO	3	/* TX zerocopy (only sendfile now) */
 #define TLS_RX_EXPECT_NO_PAD	4	/* Attempt opportunistic zero-copy */
 #define TLS_TX_MAX_PAYLOAD_LEN	5	/* Maximum plaintext size */
+#define TLS_TX_RANDOM_PAD	6	/* TLS TX randomized record zero padding */
 
 /* Supported versions */
 #define TLS_VERSION_MINOR(ver)	((ver) & 0xFF)
@@ -196,6 +197,7 @@ enum {
 	TLS_INFO_ZC_RO_TX,
 	TLS_INFO_RX_NO_PAD,
 	TLS_INFO_TX_MAX_PAYLOAD_LEN,
+	TLS_INFO_TX_RANDOM_PAD,
 	__TLS_INFO_MAX,
 };
 #define TLS_INFO_MAX (__TLS_INFO_MAX - 1)
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index b0702effbc26..62c525afbc14 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -563,6 +563,30 @@ static int do_tls_getsockopt_tx_payload_len(struct sock *sk, char __user *optval
 	return 0;
 }
 
+static int do_tls_getsockopt_tx_random_pad(struct sock *sk, char __user *optval,
+					   int __user *optlen)
+{
+	struct tls_context *ctx = tls_get_ctx(sk);
+	u16 pad_limit = ctx->tx_record_zero_pad;
+	int len;
+
+	if (ctx->prot_info.version != TLS_1_3_VERSION)
+		return -EOPNOTSUPP;
+
+	if (get_user(len, optlen))
+		return -EFAULT;
+
+	if (len < sizeof(pad_limit))
+		return -EINVAL;
+
+	if (put_user(sizeof(pad_limit), optlen))
+		return -EFAULT;
+
+	if (copy_to_user(optval, &pad_limit, sizeof(pad_limit)))
+		return -EFAULT;
+
+	return 0;
+}
 static int do_tls_getsockopt(struct sock *sk, int optname,
 			     char __user *optval, int __user *optlen)
 {
@@ -585,6 +609,9 @@ static int do_tls_getsockopt(struct sock *sk, int optname,
 	case TLS_TX_MAX_PAYLOAD_LEN:
 		rc = do_tls_getsockopt_tx_payload_len(sk, optval, optlen);
 		break;
+	case TLS_TX_RANDOM_PAD:
+		rc = do_tls_getsockopt_tx_random_pad(sk, optval, optlen);
+		break;
 	default:
 		rc = -ENOPROTOOPT;
 		break;
@@ -860,6 +887,33 @@ static int do_tls_setsockopt_tx_payload_len(struct sock *sk, sockptr_t optval,
 	return 0;
 }
 
+static int do_tls_setsockopt_tx_random_pad(struct sock *sk, sockptr_t optval,
+					   unsigned int optlen)
+{
+	struct tls_context *ctx = tls_get_ctx(sk);
+	struct tls_sw_context_tx *sw_ctx = tls_sw_ctx_tx(ctx);
+	u16 value;
+
+	if (ctx->prot_info.version != TLS_1_3_VERSION)
+		return -EOPNOTSUPP;
+
+	if (sw_ctx && sw_ctx->open_rec)
+		return -EBUSY;
+
+	if (sockptr_is_null(optval) || optlen != sizeof(value))
+		return -EINVAL;
+
+	if (copy_from_sockptr(&value, optval, sizeof(value)))
+		return -EFAULT;
+
+	if (value >= ctx->tx_max_payload_len)
+		return -EINVAL;
+
+	ctx->tx_record_zero_pad = value;
+
+	return 0;
+}
+
 static int do_tls_setsockopt(struct sock *sk, int optname, sockptr_t optval,
 			     unsigned int optlen)
 {
@@ -886,6 +940,11 @@ static int do_tls_setsockopt(struct sock *sk, int optname, sockptr_t optval,
 		rc = do_tls_setsockopt_tx_payload_len(sk, optval, optlen);
 		release_sock(sk);
 		break;
+	case TLS_TX_RANDOM_PAD:
+		lock_sock(sk);
+		rc = do_tls_setsockopt_tx_random_pad(sk, optval, optlen);
+		release_sock(sk);
+		break;
 	default:
 		rc = -ENOPROTOOPT;
 		break;
@@ -1173,6 +1232,13 @@ static int tls_get_info(struct sock *sk, struct sk_buff *skb, bool net_admin)
 	if (err)
 		goto nla_failure;
 
+	if (version != TLS_1_3_VERSION) {
+		err = nla_put_u16(skb, TLS_INFO_TX_RANDOM_PAD,
+				  ctx->tx_record_zero_pad);
+		if (err)
+			goto nla_failure;
+	}
+
 	rcu_read_unlock();
 	nla_nest_end(skb, start);
 	return 0;
@@ -1185,6 +1251,7 @@ static int tls_get_info(struct sock *sk, struct sk_buff *skb, bool net_admin)
 
 static size_t tls_get_info_size(const struct sock *sk, bool net_admin)
 {
+	struct tls_context *ctx = tls_get_ctx(sk);
 	size_t size = 0;
 
 	size += nla_total_size(0) +		/* INET_ULP_INFO_TLS */
@@ -1197,6 +1264,9 @@ static size_t tls_get_info_size(const struct sock *sk, bool net_admin)
 		nla_total_size(sizeof(u16)) +   /* TLS_INFO_TX_MAX_PAYLOAD_LEN */
 		0;
 
+	if (ctx->prot_info.version == TLS_1_3_VERSION)
+		size += nla_total_size(sizeof(u16)); /* TLS_INFO_TX_RANDOM_PAD */
+
 	return size;
 }
 
-- 
2.53.0

[RFC net-next 3/3] selftest: tls: add tls record zero pad test

[Wilfred Mallawa]

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

Enable record zero padding using the TLS_TX_RANDOM_PAD socket option for
a TLS1.3 connection. This only tests the setsockopt()/getsockopt()
invocations as padding is processed in the kernel.

Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
---
 tools/testing/selftests/net/tls.c | 45 +++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/tools/testing/selftests/net/tls.c b/tools/testing/selftests/net/tls.c
index 9e2ccea13d70..a72ba8607ead 100644
--- a/tools/testing/selftests/net/tls.c
+++ b/tools/testing/selftests/net/tls.c
@@ -2997,6 +2997,51 @@ TEST(tls_12_tx_max_payload_len_open_rec)
 	close(fd);
 }
 
+TEST(tls_13_tx_record_zero_padding)
+{
+	struct tls_crypto_info_keys tls13;
+	char const *tx = "how much wood could a woodchuck chuck";
+	int tx_len = strlen(tx) + 1;
+	__u8 rx[4096];
+	__u16 opt, zpad = 2048;
+	unsigned int optlen = sizeof(opt);
+	bool notls;
+	int ret, tx_fd, rx_fd;
+
+	tls_crypto_info_init(TLS_1_3_VERSION, TLS_CIPHER_AES_GCM_128,
+			     &tls13, 1);
+
+	ulp_sock_pair(_metadata, &rx_fd, &tx_fd, &notls);
+	if (notls)
+		exit(KSFT_SKIP);
+
+	/* Setup Keys */
+	ret = setsockopt(tx_fd, SOL_TLS, TLS_TX, &tls13, tls13.len);
+	ASSERT_EQ(ret, 0);
+
+	ret = setsockopt(rx_fd, SOL_TLS, TLS_RX, &tls13, tls13.len);
+	ASSERT_EQ(ret, 0);
+
+	ret = setsockopt(tx_fd, SOL_TLS, TLS_TX_RANDOM_PAD, &zpad,
+			 sizeof(zpad));
+	ASSERT_EQ(ret, 0);
+
+	ret = getsockopt(tx_fd, SOL_TLS, TLS_TX_RANDOM_PAD, &opt, &optlen);
+	EXPECT_EQ(ret, 0);
+	EXPECT_EQ(zpad, opt);
+	EXPECT_EQ(optlen, sizeof(zpad));
+
+	ASSERT_EQ(send(tx_fd, tx, tx_len, MSG_EOR), tx_len);
+	close(tx_fd);
+
+	ret = recv(rx_fd, rx, sizeof(rx), 0);
+	ASSERT_GE(ret, 0);
+	ASSERT_LE(tx_len, ret);
+	EXPECT_EQ(memcmp(rx, tx, tx_len), 0);
+
+	close(rx_fd);
+}
+
 TEST(non_established) {
 	struct tls12_crypto_info_aes_gcm_256 tls12;
 	struct sockaddr_in addr;
-- 
2.53.0

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

[Sabrina Dubroca]

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

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Sabrina Dubroca]

2026-03-09, 15:48:36 +1000, Wilfred Mallawa wrote:
> 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, 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?

> 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)]).
> 
> For TLS 1.3, zero padding is added after the content type byte, as such,
> if the record in context meets the above conditions for zero padding,
> attach a zero padding buffer to the content type byte before a record is
> encrypted. The padding buffer is freed when the record is freed.
> 
> By default, record zero padding is disabled, and userspace may enable it
> by using the setsockopt TLS_TX_RANDOM_PAD option.
> 
> [1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4l

nit: there's a stray 'l' at the end of that link (and other references
to that section in your commit messages within the series)


> @@ -1033,6 +1055,8 @@ static int tls_sw_sendmsg_locked(struct sock *sk, struct msghdr *msg,
>  	unsigned char record_type = TLS_RECORD_TYPE_DATA;
>  	bool is_kvec = iov_iter_is_kvec(&msg->msg_iter);
>  	bool eor = !(msg->msg_flags & MSG_MORE);
> +	bool tls_13 = (prot->version == TLS_1_3_VERSION);
> +	bool rec_zero_pad = eor && tls_13 && tls_ctx->tx_record_zero_pad;

Thus here, rec_zero_pad would simply be tls_ctx->tx_record_zero_pad
(the tls_13 check should be redundant I think?).


> @@ -1085,8 +1110,19 @@ static int tls_sw_sendmsg_locked(struct sock *sk, struct msghdr *msg,
>  			full_record = true;
>  		}
>  
> +		if (rec_zero_pad && !full_record)
> +			zero_pad_len = record_room - try_to_copy;

And I would turn this logic the other way around:

 - decide zero_pad_len (get_random if that's the API approach we want,
   discussion in the cover letter) for every new record
 - adjust record_room based on that
 - then see if the record will be full


(I'll postpone looking at the actual implementation for now)

-- 
Sabrina

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Jakub Kicinski]

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 <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, 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?

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Wilfred Mallawa]

On Fri, 2026-03-13 at 14:16 +0100, Sabrina Dubroca wrote:
> 2026-03-09, 15:48:36 +1000, Wilfred Mallawa wrote:
> > 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, 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?
> 

hmm it does... but also, I am not sure if chunking records solely to
introduce zero padding is a good idea either? is the added overhead
worth it? For example, the NVMe TCP/TLS usecase, I think this would
slow things down noticeably. The current approach is meant to be a
balance between some of the security benefits and performance.

But as you mentioned, we can introduce a fixed size option, such that
all outgoing records are padded to the max record size. Which should
address security concern the above (?) ... at the cost of performance,
this provides a stronger padding policy, and would keep the logic quite
simple?

For context, testing with NVMe TCP TLS we saw a ~50% reduction in
performance (4K Write IOPs) when padding all outgoing records to the
maximum record size limit. 

> > 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)]).
> > 
> > For TLS 1.3, zero padding is added after the content type byte, as
> > such,
> > if the record in context meets the above conditions for zero
> > padding,
> > attach a zero padding buffer to the content type byte before a
> > record is
> > encrypted. The padding buffer is freed when the record is freed.
> > 
> > By default, record zero padding is disabled, and userspace may
> > enable it
> > by using the setsockopt TLS_TX_RANDOM_PAD option.
> > 
> > [1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4l
> 
> nit: there's a stray 'l' at the end of that link (and other
> references
> to that section in your commit messages within the series)
> 

oops! missed that... thanks!

> 
> > @@ -1033,6 +1055,8 @@ static int tls_sw_sendmsg_locked(struct sock
> > *sk, struct msghdr *msg,
> >  	unsigned char record_type = TLS_RECORD_TYPE_DATA;
> >  	bool is_kvec = iov_iter_is_kvec(&msg->msg_iter);
> >  	bool eor = !(msg->msg_flags & MSG_MORE);
> > +	bool tls_13 = (prot->version == TLS_1_3_VERSION);
> > +	bool rec_zero_pad = eor && tls_13 && tls_ctx-
> > >tx_record_zero_pad;
> 
> Thus here, rec_zero_pad would simply be tls_ctx->tx_record_zero_pad
> (the tls_13 check should be redundant I think?).

Ah yes, it is checked in the setsockopt()!


Wilfred

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Wilfred Mallawa]

On Sat, 2026-03-14 at 07:39 -0700, Jakub Kicinski wrote:
> 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 <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, 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?

For upcoming WD hardware, we were planning on informing users to use
this feature if an extra layer of security can benefit their particular
configuration. But to answer your question, I think this falls more
into the "checking a box"...

I'm happy to drop this series if there's not much added value from
having this as an available option for users.

> 
> Second question - do we also need to support zero-byte records
> (entire
> record is padding) to prevent timing attacks?

That's a good point, although it is not needed, having it could benefit
in timing attacks. As RFC8446 [1] puts it, 
"This permits generation of plausibly sized cover traffic in contexts
where the presence or absence of activity may be sensitive."

I can look into that if we are going ahead with this series...

Regards,
Wilfred

[1] https://datatracker.ietf.org/doc/html/rfc8446#section-5.4

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

[Wilfred Mallawa]

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

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

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Jakub Kicinski]

On Tue, 17 Mar 2026 00:53:07 +0000 Wilfred Mallawa wrote:
> > 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?  
> 
> For upcoming WD hardware, we were planning on informing users to use
> this feature if an extra layer of security can benefit their particular
> configuration. But to answer your question, I think this falls more
> into the "checking a box"...
> 
> I'm happy to drop this series if there's not much added value from
> having this as an available option for users.

I'm not much of a security person, and maybe Sabrina will disagree
but I feel like it's going to be hard for us to design this feature
in a sensible way if we don't know at least one potential attack :S

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Wilfred Mallawa]

On Mon, 2026-03-16 at 18:03 -0700, Jakub Kicinski wrote:
> On Tue, 17 Mar 2026 00:53:07 +0000 Wilfred Mallawa wrote:
> > > 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?  
> > 
> > For upcoming WD hardware, we were planning on informing users to
> > use
> > this feature if an extra layer of security can benefit their
> > particular
> > configuration. But to answer your question, I think this falls more
> > into the "checking a box"...
> > 
> > I'm happy to drop this series if there's not much added value from
> > having this as an available option for users.
> 
> I'm not much of a security person, and maybe Sabrina will disagree
> but I feel like it's going to be hard for us to design this feature
> in a sensible way if we don't know at least one potential attack :S

Traffic analysis is the attack vector we are trying to mitigate against
with zero padding, which TLS is susceptible to [1]. I think the hard
part is deciding the padding policy and balancing it such that we have
sensible performance.

This series adds random padding to records with room, a stronger policy
I think would be to pad all records to max record size length. But that
adds a much higher performance overhead. For context, when testing NVMe
TCP+TLS with 4K writes with a record size limit of 4k, we observed a
50% reduction in IOPs on the fixed max record pad policy as opposed to
the random padding policy from this series.

Wilfred

[1] https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.3

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Jakub Kicinski]

On Tue, 17 Mar 2026 01:21:12 +0000 Wilfred Mallawa wrote:
> On Mon, 2026-03-16 at 18:03 -0700, Jakub Kicinski wrote:
> > On Tue, 17 Mar 2026 00:53:07 +0000 Wilfred Mallawa wrote:  
>  [...]  
> > > 
> > > For upcoming WD hardware, we were planning on informing users to
> > > use
> > > this feature if an extra layer of security can benefit their
> > > particular
> > > configuration. But to answer your question, I think this falls more
> > > into the "checking a box"...
> > > 
> > > I'm happy to drop this series if there's not much added value from
> > > having this as an available option for users.  
> > 
> > I'm not much of a security person, and maybe Sabrina will disagree
> > but I feel like it's going to be hard for us to design this feature
> > in a sensible way if we don't know at least one potential attack :S  
> 
> Traffic analysis is the attack vector we are trying to mitigate against
> with zero padding, which TLS is susceptible to [1]. I think the hard
> part is deciding the padding policy and balancing it such that we have
> sensible performance.
> 
> This series adds random padding to records with room, a stronger policy
> I think would be to pad all records to max record size length. But that
> adds a much higher performance overhead. For context, when testing NVMe
> TCP+TLS with 4K writes with a record size limit of 4k, we observed a
> 50% reduction in IOPs on the fixed max record pad policy as opposed to
> the random padding policy from this series.

Sorry, I realized when i hit "send" that I phrased my previous message
poorly. When I say "potential" I mean someone actually presenting a PoC
and a CVE is issued for it. Have we seen any of those?

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Wilfred Mallawa]

On Mon, 2026-03-16 at 18:30 -0700, Jakub Kicinski wrote:
> On Tue, 17 Mar 2026 01:21:12 +0000 Wilfred Mallawa wrote:
> > On Mon, 2026-03-16 at 18:03 -0700, Jakub Kicinski wrote:
> > > On Tue, 17 Mar 2026 00:53:07 +0000 Wilfred Mallawa wrote:  
> >  [...]  
> > > > 
> > > > For upcoming WD hardware, we were planning on informing users
> > > > to
> > > > use
> > > > this feature if an extra layer of security can benefit their
> > > > particular
> > > > configuration. But to answer your question, I think this falls
> > > > more
> > > > into the "checking a box"...
> > > > 
> > > > I'm happy to drop this series if there's not much added value
> > > > from
> > > > having this as an available option for users.  
> > > 
> > > I'm not much of a security person, and maybe Sabrina will
> > > disagree
> > > but I feel like it's going to be hard for us to design this
> > > feature
> > > in a sensible way if we don't know at least one potential attack
> > > :S  
> > 
> > Traffic analysis is the attack vector we are trying to mitigate
> > against
> > with zero padding, which TLS is susceptible to [1]. I think the
> > hard
> > part is deciding the padding policy and balancing it such that we
> > have
> > sensible performance.
> > 
> > This series adds random padding to records with room, a stronger
> > policy
> > I think would be to pad all records to max record size length. But
> > that
> > adds a much higher performance overhead. For context, when testing
> > NVMe
> > TCP+TLS with 4K writes with a record size limit of 4k, we observed
> > a
> > 50% reduction in IOPs on the fixed max record pad policy as opposed
> > to
> > the random padding policy from this series.
> 
> Sorry, I realized when i hit "send" that I phrased my previous
> message
> poorly. When I say "potential" I mean someone actually presenting a
> PoC
> and a CVE is issued for it. Have we seen any of those?

Ah right, I haven't seen any PoC/CVEs which could directly be addressed
by zero padding.

Wilfred

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Sabrina Dubroca]

2026-03-16, 18:03:55 -0700, Jakub Kicinski wrote:
> On Tue, 17 Mar 2026 00:53:07 +0000 Wilfred Mallawa wrote:
> > > 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?  
> > 
> > For upcoming WD hardware, we were planning on informing users to use
> > this feature if an extra layer of security can benefit their particular
> > configuration. But to answer your question, I think this falls more
> > into the "checking a box"...
> > 
> > I'm happy to drop this series if there's not much added value from
> > having this as an available option for users.
> 
> I'm not much of a security person, and maybe Sabrina will disagree
> but I feel like it's going to be hard for us to design this feature
> in a sensible way if we don't know at least one potential attack :S

No, same here, that's why I tried to CC some userspace developers on
the cover (as well as for awareness of what's going on in the kernel
and the API being discussed -- adding them here again).

My understanding is that attacks of this type are mainly "observers
will figure out what type of traffic I'm doing based on message
length", and I feel all those "traffic pattern masking" features are
only interesting for very paranoid users. The RFC links to some
research, and maybe the kind of statistics/machine learning that those
attacks require has improved since, which could make such attacks more
realistic? No idea.

-- 
Sabrina

Re: [RFC net-next 1/3] net/tls_sw: support randomized zero padding

[Alistair Francis]

On Tue, 2026-03-17 at 01:53 +0000, Wilfred Mallawa wrote:
> On Mon, 2026-03-16 at 18:30 -0700, Jakub Kicinski wrote:
> > On Tue, 17 Mar 2026 01:21:12 +0000 Wilfred Mallawa wrote:
> > > On Mon, 2026-03-16 at 18:03 -0700, Jakub Kicinski wrote:
> > > > On Tue, 17 Mar 2026 00:53:07 +0000 Wilfred Mallawa wrote:  
> > >  [...]  
> > > > > 
> > > > > For upcoming WD hardware, we were planning on informing users
> > > > > to
> > > > > use
> > > > > this feature if an extra layer of security can benefit their
> > > > > particular
> > > > > configuration. But to answer your question, I think this
> > > > > falls
> > > > > more
> > > > > into the "checking a box"...
> > > > > 
> > > > > I'm happy to drop this series if there's not much added value
> > > > > from
> > > > > having this as an available option for users.  
> > > > 
> > > > I'm not much of a security person, and maybe Sabrina will
> > > > disagree
> > > > but I feel like it's going to be hard for us to design this
> > > > feature
> > > > in a sensible way if we don't know at least one potential
> > > > attack
> > > > :S  
> > > 
> > > Traffic analysis is the attack vector we are trying to mitigate
> > > against
> > > with zero padding, which TLS is susceptible to [1]. I think the
> > > hard
> > > part is deciding the padding policy and balancing it such that we
> > > have
> > > sensible performance.
> > > 
> > > This series adds random padding to records with room, a stronger
> > > policy
> > > I think would be to pad all records to max record size length.
> > > But
> > > that
> > > adds a much higher performance overhead. For context, when
> > > testing
> > > NVMe
> > > TCP+TLS with 4K writes with a record size limit of 4k, we
> > > observed
> > > a
> > > 50% reduction in IOPs on the fixed max record pad policy as
> > > opposed
> > > to
> > > the random padding policy from this series.
> > 
> > Sorry, I realized when i hit "send" that I phrased my previous
> > message
> > poorly. When I say "potential" I mean someone actually presenting a
> > PoC
> > and a CVE is issued for it. Have we seen any of those?

In 2014 a group at UC Berkeley used HTTPS traffic analysis to identify:

"individual pages in the same web-site with 90% accuracy, exposing
personal details including medical conditions, financial and legal
affairs and sexual orientation."

They used machine learning to help and that was over 10 years ago. So I
suspect modern day machine learning would make this even easier to do
today.

Obviously that is HTTP traffic, which is different to the NVMe-TCP
traffic this series is targeting, but it does still seem like a real
concern.

They talk about a range of defences in the paper, with tradeoffs
between all of them. But the linear defence seems like the one that is
applicable here:

"linear defense pads all packet sizes up to multiples of 128"

The linear defence seems to reduce the Pan attack from 60% to around
25% and the BoG attack from 90% to around 60%.

On top of that the

"Burst defense offers greater protection, operating between the TCP
layer and application layer to pad contiguous bursts of traffic up to 
predefined thresholds uniquely determined for each website"

Which to me sounds like the random padding proposed in this series
would provide more protection then the basic linear padding used in the
paper.

To me analysing TLS traffic does seem like a plausible threat and
something that randomised padding would help with. Leaving it up to
userspace to decide based on their threat model seems like a good
approach as well.

1: https://secml.cs.berkeley.edu/pets2014/

Alistair

> 
> Ah right, I haven't seen any PoC/CVEs which could directly be
> addressed
> by zero padding.
> 
> Wilfred