Re: [PATCH net-next v4 4/5] tls: send a KeyUpdate at the record limit and on request
From: Hannes Reinecke
Date: Tue Nov 03 2026 - 02:18:39 EST
On 11/2/26 5:58 PM, Martin Belanger via B4 Relay wrote:
From: Martin Belanger <martin.belanger@xxxxxxxx>Reviewed-by: Hannes Reinecke <hare@xxxxxxxxxx>
RFC 9846 section 5.5 requires a key update before the key reaches its
usage limit, 2^24.5 full-size records for AES-GCM. The limit counts
records, and only the record layer knows where records start and end.
Section 4.7.3 also requires a reply to a KeyUpdate with
update_requested, sent before the next Application Data record. Both
need a KeyUpdate at an exact position in the record stream.
For a socket with a registered TX secret, send a KeyUpdate before the
next Application Data record when the key has protected 2^24 records, as
GnuTLS does, or when the peer asked for one. ChaCha20-Poly1305 has no
record limit. The KeyUpdate is sent as a handshake record, which closes
the open data record first. Pending encryptions are then completed, and
only then is the next key installed.
Add TLS_TX_KEY_UPDATE to send a KeyUpdate now, optionally asking the
peer to update too. It can only bring a KeyUpdate forward: the record
limit is enforced either way. Following section 4.7.3, a new request
to the peer waits for the answer to the previous one, and no more than
2^48-1 epochs are used.
Signed-off-by: Martin Belanger <martin.belanger@xxxxxxxx>
---
Documentation/networking/tls.rst | 17 +++++
include/net/tls.h | 5 +-
include/uapi/linux/tls.h | 1 +
net/tls/tls.h | 1 +
net/tls/tls_keyupdate.c | 5 ++
net/tls/tls_main.c | 38 +++++++++-
net/tls/tls_sw.c | 160 +++++++++++++++++++++++++++++++++++++++
7 files changed, 225 insertions(+), 2 deletions(-)
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +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