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

[Martin Belanger]

On 10/28/26 10:42, Hannes Reinecke wrote:
> On 10/28/26 3:21 PM, Chuck Lever wrote:
> > 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.
> Yes. But Martin send already a patchset for that (well, for NVMe, at 
> least).

Thanks, Hannes. Two points to add.

A reconnect is also a valid answer to the record limit: RFC 9846
section 5.5 allows closing the connection. The cost is the problem.
Depending on the load and link speed, the 2^24 limit can be reached in
less than 10 minutes in many cases. Each reconnect stops the I/O of the
queue and needs a new handshake upcall, for every queue of every
controller. A peer that sends KeyUpdate on its own causes the same
reconnects. With this series, the connection stays up.

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

The series does not add back the HKDF library. It computes the HMACs
inline with the HMAC library, as the NVMe PSK derivation in
drivers/nvme/common/auth.c does. That is why commit 6d888db2cfd9
removed the library. The QUIC series also derives its key updates in
the kernel.

GnuTLS does handle a received KeyUpdate with kTLS since kernel 6.14,
but only when user space keeps the GnuTLS session. tlshd does not: it
hands the socket to the kernel after the handshake. So the library
cannot help nvme-tcp or sunrpc here.

Martin.

> Yes. TLS KeyUpdate requires that all records _after_ the KeyUpdate 
> message are encrypted with the next key; idea is here that one can
> (and should) do this in-line without stopping/resetting the connection.
> _And_ TLS KeyUpdate is done independently on the RX and the TX side.
>
> This makes it extremely hard to implement via tlshd; we would need
> to pass the KeyUpdate message to tlshd (which is easy), but then
> we would need to stop processing incoming packets until we get
> a response from tlshd indicating that it has installed the new
> secret.
>
> Which makes the whole idea of KeyUpdate (namely that you can
> do it _without_ stopping packet processing) a bit pointless.
>
> And I haven't even mentioned that you would need to be able to
> stop RX and TX _independently_, which I'm not sure the various
> ULPs can do.
>
> Plus there is the question why ULPs need to be burdened with
> protocol specific knowledge; why would I need to code hooks/
> handling for an extremely protocol-specific know?
> It's far better be handled by the protocol itself.
>
> > 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) ?
> No. This is not about the certificate, it's about traffic secrets.
> If a certificate is expired you need to reset the connection
> to install a new certificate; TLS 1.3 does not allow you to do
> that while the connection is established.
> And handling of expired certificates is an admin choice, not
> something one should do automatically.
>
> (The last thing you want is your root fs becoming inaccessible
> just because a lazy admin forgot to renew the certificate ...)
>
> Cheers,
>
> Hannes