TLS 1.3 KeyUpdate: should kTLS handle it instead of the tlshd upcall?

@chucklever, @hreinecke — attached is a design document (revision 9) proposing that kTLS handles TLS 1.3 KeyUpdate itself, rather than through an upcall to tlshd. This note covers how I got there and what I am asking.
The document is attached as both Markdown and HTML. The text is identical; the HTML is easier to read in a browser.

tls-keyupdate-design-v9.html

tls-keyupdate-design-v9.md

How I got here

I started from a failure in NVMe/TCP. A colleague at Dell reproduced a silent, indefinite stall of an I/O queue when the peer sent a KeyUpdate, on an unmodified 6.17 kernel. Nothing was logged, and the controller kept reporting state = live.

That led to net/tls, where kTLS detects the record, sets key_update_pending and returns -EKEYEXPIRED with the comment "let userspace deal with it". For NVMe/TCP there is no userspace to deal with it.

Looking for prior work I found ktls-utils issue #29 and, through Hannes's comment there, Alistair Francis's series "nvme-tcp: Support receiving KeyUpdate requests" (v7, 2026-03-04). It solves the RX half through an upcall to tlshd, and is not merged. Reading it raised the question this document asks: whether the problem is better solved inside the kernel.

Two things turned out to be broader than the NVMe case. The TX half affects every kTLS user: the kernel owns the record count and exposes it only as a snapshot to poll, so no library enforces the RFC 8446 §5.5 limit under offload. And the RX half affects both in-tree consumers — sunrpc discards a received KeyUpdate as an unknown record type, in both the client and the server path. I have read that code but not tested it.

That second point is why I am raising this here rather than as an NVMe issue.

What I am asking

1. Is this a reasonable reading of the problem, or is there an architectural or kTLS-specific reason why KeyUpdate should not be handled in the kernel? I could not find that discussion in the v1 to v7 threads or in issue #29. If there is a reason, that answer is more useful than the proposal.
2. Chuck — you wrote the record-type handling in both xprtsock.c and svcsock.c, so this one is really for you: is the sunrpc behavior in section 2.3 what you would expect, and has it been seen in practice?
3. Most of the work is in net/tls, where I have no established contact. Who should this go to on netdev, and would either of you be willing to introduce it? Sabrina Dubroca wrote the existing rekey support, so that seems like the right starting point.

Nothing here is meant to dismiss the existing series. It carries a Reviewed-by from both of you and it addresses a real bug. My question is about the long-term home for the functionality, not about the work already done.

How the document was produced

I used Claude to help analyze the code and draft the document. It worked across five trees — the kernel, ktls-utils, GnuTLS, OpenSSL and the v7 series — which is more cross-referencing than I would have done by hand, and it is how the sunrpc case surfaced at all.

I mention it because the document makes specific claims about code in projects I do not maintain. Every one is cited to a file and line number, the exact tree revisions are in Appendix D, and anything that was read but not tested says so. If a citation is wrong I would like to know; the argument should stand or fall on the code, not on how the text was assembled.

Start with the attached tls-keyupdate-design-v9.md or HTML document, then read the cited net/tls code and the KeyUpdate handling in xprtsock.c and svcsock.c. Review ktls-utils issue #29 and the referenced v7 NVMe-TCP series. Done means reaching and documenting an architectural decision about kernel versus tlshd handling, including the stated TX and RX concerns.