From 6d9924463a7c3412aab7a614cb6f5d3876951c9b Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Tue, 19 Mar 2024 13:49:55 +1000 Subject: [PATCH 1/2] Forbid the sender from sending redundant update_requested KeyUpdates Otherwise we run into the issue described in issue #1341. Fixes #1341 --- draft-ietf-tls-rfc8446bis.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index c67cfb4e..7f895597 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -3566,7 +3566,10 @@ send a KeyUpdate of its own with request_update set to "update_not_requested" pr to sending its next Application Data record. This mechanism allows either side to force an update to the entire connection, but causes an implementation which receives multiple KeyUpdates while it is silent to respond with -a single update. Note that implementations may receive an arbitrary +a single update. Until receiving the peer's response, the sender MUST NOT send +another KeyUpdate with request_update set to "update_requested". + +Note that implementations may receive an arbitrary number of messages between sending a KeyUpdate with request_update set to "update_requested" and receiving the peer's KeyUpdate, because those messages may already be in flight. From f2a555437974c4754a61a9b65ec1fbe14cf543d6 Mon Sep 17 00:00:00 2001 From: David Benjamin Date: Wed, 12 Jun 2024 16:13:31 -0400 Subject: [PATCH 2/2] Update with suggestion from Kyle Nekritz --- draft-ietf-tls-rfc8446bis.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/draft-ietf-tls-rfc8446bis.md b/draft-ietf-tls-rfc8446bis.md index 7f895597..f5c8d663 100644 --- a/draft-ietf-tls-rfc8446bis.md +++ b/draft-ietf-tls-rfc8446bis.md @@ -3566,13 +3566,15 @@ send a KeyUpdate of its own with request_update set to "update_not_requested" pr to sending its next Application Data record. This mechanism allows either side to force an update to the entire connection, but causes an implementation which receives multiple KeyUpdates while it is silent to respond with -a single update. Until receiving the peer's response, the sender MUST NOT send -another KeyUpdate with request_update set to "update_requested". +a single update. Until receiving a subsequent KeyUpdate from the peer, the +sender MUST NOT send another KeyUpdate with request_update set to +"update_requested". Note that implementations may receive an arbitrary number of messages between sending a KeyUpdate with request_update set to "update_requested" and receiving the -peer's KeyUpdate, because those messages may already be in flight. +peer's KeyUpdate, including unrelated KeyUpdates, because those messages may +already be in flight. However, because send and receive keys are derived from independent traffic secrets, retaining the receive traffic secret does not threaten the forward secrecy of data sent before the sender changed keys.