netdev - 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: <96ca4de7-d647-47ac-b42f-d76284394526@oracle.com>
Date: Tue, 29 Jul 2025 09:37:41 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: Wilfred Mallawa <wilfred.opensource@...il.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,
        Wilfred Mallawa <wilfred.mallawa@....com>
Subject: Re: [RFC 0/4] net/tls: add support for the record size limit
 extension

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?


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


> [1] https://www.rfc-editor.org/rfc/rfc8449
> [2] https://github.com/oracle/ktls-utils/pull/112
> [3] https://gitlab.com/gnutls/gnutls/-/merge_requests/1989
> 
> Wilfred Mallawa (4):
>   net/handshake: get negotiated tls record size limit
>   net/tls/tls_sw: use the record size limit specified
>   nvme/host/tcp: set max record size in the tls context
>   nvme/target/tcp: set max record size in the tls context
> 
>  Documentation/netlink/specs/handshake.yaml |  3 +++
>  Documentation/networking/tls-handshake.rst |  8 +++++++-
>  drivers/nvme/host/tcp.c                    | 18 +++++++++++++++++-
>  drivers/nvme/target/tcp.c                  | 16 +++++++++++++++-
>  include/net/handshake.h                    |  4 +++-
>  include/net/tls.h                          |  1 +
>  include/uapi/linux/handshake.h             |  1 +
>  net/handshake/genl.c                       |  5 +++--
>  net/handshake/tlshd.c                      | 15 +++++++++++++--
>  net/sunrpc/svcsock.c                       |  4 +++-
>  net/sunrpc/xprtsock.c                      |  4 +++-
>  net/tls/tls_sw.c                           | 10 +++++++++-
>  12 files changed, 78 insertions(+), 11 deletions(-)
> 


-- 
Chuck Lever