linux-kernel - Re: [RFC 0/4] net/tls: add support for the record size limit extension

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <7af292c6bb2c42cead77202a9034fcb6111b898c.camel@gmail.com>
Date: Thu, 07 Aug 2025 10:14:14 +1000
From: Wilfred Mallawa <wilfred.opensource@...il.com>
To: Chuck Lever <chuck.lever@...cle.com>, alistair.francis@....com, 
	dlemoal@...nel.org, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, 	pabeni@...hat.com, horms@...nel.org,
 donald.hunter@...il.com, corbet@....net, 	kbusch@...nel.org,
 axboe@...nel.dk, hch@....de, sagi@...mberg.me, kch@...dia.com, 
	borisp@...dia.com, john.fastabend@...il.com, jlayton@...nel.org,
 neil@...wn.name, 	okorniev@...hat.com, Dai.Ngo@...cle.com, tom@...pey.com,
 trondmy@...nel.org, 	anna@...nel.org, kernel-tls-handshake@...ts.linux.dev,
 netdev@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-nvme@...ts.infradead.org, linux-nfs@...r.kernel.org
Subject: Re: [RFC 0/4] net/tls: add support for the record size limit
 extension

Hey Chuck,

On Tue, 2025-07-29 at 09:37 -0400, Chuck Lever wrote:
> Hi Wilfred -
> 
> On 7/28/25 10:41 PM, Wilfred Mallawa wrote:
> > From: Wilfred Mallawa <wilfred.mallawa@....com>
> > 
> > During a tls handshake, an endpoint may specify a maximum record
> > size limit. As
> > specified by [1]. which allows peers to negotiate a maximum
> > plaintext record
> > size during the TLS handshake. If a TLS endpoint receives a record
> > larger
> > than its advertised limit, it must send a fatal "record_overflow"
> > alert [1].
> > Currently, this limit is not visble to the kernel, particularly in
> > the case
> > where userspace handles the handshake (tlshd/gnutls).
> 
> This paragraph essentially says "The spec says we can, so I'm
> implementing it". Generally we don't implement spec features just
> because they are there.
> 
> What we reviewers need instead is a problem statement. What is not
> working for you, and why is this the best way to solve it?
Thanks for the feedback.

Essentially, this is to support upcoming WD NVMe-TCP controller that
implements TLS support. These devices require record size negotiation
as they support a maximum record size less than the current kernel
default. I will add this to my V2 series in more detail.
> 
> 
> > This series in conjunction with the respective userspace changes
> > for tlshd [2]
> > and gnutls [3], adds support for the kernel the receive the
> > negotiated record
> > size limit through the existing netlink communication layer, and
> > use this
> > value to limit outgoing records to the size specified.
> 
> As Hannes asked elsewhere, why is it up to the TLS consumer to be
> aware of this limit? Given the description here, it sounds to me
> like something that should be handled for all consumers by the TLS
> layer.
Yeah great point, I didn't think it through too well. I will address
this in V2 and have the record size limit implemented in the TLS layer
without involving ULPs.

Regards,
Wilfred