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

[Hannes Reinecke]

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

> 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.
> 
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
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare at suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich