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

[Chuck Lever]

On Wed, Oct 28, 2026, at 10:49 AM, Martin Belanger wrote:
> On Wed, Oct 28, 2026 at 10:42 AM Hannes Reinecke <hare@xxxxxxx> wrote:
>
> Thanks, Hannes. Two points to add.
>
> On 10/28/26 3:21 PM, Chuck Lever wrote:

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

I get that dropping the connection is bad; the current weak-ass
implementation is meant to handle KeyUpdate until we have a proper
spec-conformant implementation.

My concern here is if the current design is malfunctioning in LTS
kernels, the only mechanism we have is to fix it upstream and backport
the fix. I don't believe stable@ would be happy absorbing this full
series.

Your commit message claims the connection stalls rather than getting
replaced. If that's true, that needs to be fixed before this series
gets merged. Can you confirm? I don't expect such a fix would be large,
but the ordering matters.


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