Re: [PATCH RFC net-next v2 0/5] tls: perform TLS 1.3 KeyUpdate in the kernel

["Chuck Lever" <cel@kernel.org>]

On Wed, Oct 28, 2026, at 9:52 AM, Martin Belanger via B4 Relay wrote:
> kTLS does not currently handle TLS 1.3 KeyUpdate. It never sends a
> KeyUpdate. And when it receives one, it blocks the socket until the
> application installs the next key. kTLS also does not enforce the key
> usage limit on transmit.

No argument here.


> This applies to TLS libraries in user space as well as kernel users such
> as NVMe/TCP or sunrpc:
>
> - GnuTLS sends a KeyUpdate after 2^24 records when it runs its own
>   record layer. With kTLS, the record layer is handled in the kernel and
>   GnuTLS therefore never runs the check. OpenSSL never sends a KeyUpdate
>   on its own.
> - NVMe/TCP and sunrpc don't have a mechanism to install a new key. A
>   conforming peer that sends a KeyUpdate stalls their connection.

The design intention of these consumers is that they are supposed to break
the connection and create a new session, rather than stall. If that is not
happening, that's a bug. KeyUpdate is complicated enough that backporting
to LTS is not really an option, so that bug needs to be addressed first,
IMHO.

The argument that was made that put tlshd in user space is that we do
not want the kernel to handle something that the libraries are already
good at (IOW, mechanisms that have been soaked in commodity usage by many
consumers).

Is that rationale different for handling TLS KeyUpdate? I see that the
series adds back the HKDF functionality to the kernel. That seems like
an indication that KeyUpdate should be handled via an upcall.

Are there policy decisions that need to be made during KeyUpdate (like,
has the peer's certificate expired, or has it been put on a revocation
list in the meantime) ?


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)