I can't parse the below line:
"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."
The fig-key-update sequence diagram does not reflect the use of ExtendedKeyUpdateRequest, ExtendedKeyUpdateResponse and NewKeyUpdate.
If implementations independently initiate the extended key update procedure, and they cross in flight, the result is that each side increments keys by two generations.
comment> Another way to handle the race condition is that ExtendedKeyUpdateRequest which has lower lexicographic order will be discarded by the TLS peer. This approach ensures that only one key update is processed, avoiding the need to compute the keys twice and thereby simplifying the process.
Alternatively, a default policy where the server has a higher precedence and in case of a race condition the ExtendedKeyUpdateRequest from the client would be discarded.
Once client_/server_application_traffic_secretN+1 and its associated
traffic keys have been computed, implementations SHOULD delete
client/server_application_traffic_secret_N and its associated
traffic keys.
comment> The client_/server_application_traffic_secret_N and its associated traffic keys can only be deleted after receiving the NewKeyUpdate message.
I would modify the application_traffic_secret_N+1 as follows:
sk = HKDF-Extract(Transcript-Hash(KeyUpdateMessages), secret) // secret derived from DH exchange or hybrid key exchange
application_traffic_secret_N+1 =
Derive-Secret(sk,"traffic upd 2",
application_traffic_secret_N)
The next generation of traffic keys is computed using the HKDF, as defined in [RFC5869], and its two components, HKDF-Extract and HKDF-Expand, as recommended in Appendix F.1.1 of [I-D.ietf-tls-rfc8446bis]. It would also ensure that client_application_traffic_secret_N+1 and sever_application_traffic_secret_N+1 are different. It also uses application_traffic_secret_N to create a binding security property to the prior key.
The step 4 discussed in "Extended Key Update Message" does not look complete to me.
Remove the following line (it does not discuss hybrid key exchange, it only refers to use of ML-KEM):
"TLS supports the hybrid key exchange based on the extension defined in {{I-D.connolly-tls-mlkem-key-agreement}}"
I can't parse the below line: "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."
The fig-key-update sequence diagram does not reflect the use of ExtendedKeyUpdateRequest, ExtendedKeyUpdateResponse and NewKeyUpdate.
If implementations independently initiate the extended key update procedure, and they cross in flight, the result is that each side increments keys by two generations.
comment> Another way to handle the race condition is that ExtendedKeyUpdateRequest which has lower lexicographic order will be discarded by the TLS peer. This approach ensures that only one key update is processed, avoiding the need to compute the keys twice and thereby simplifying the process.
Alternatively, a default policy where the server has a higher precedence and in case of a race condition the ExtendedKeyUpdateRequest from the client would be discarded.
comment> The client_/server_application_traffic_secret_N and its associated traffic keys can only be deleted after receiving the NewKeyUpdate message.
I would modify the application_traffic_secret_N+1 as follows:
sk = HKDF-Extract(Transcript-Hash(KeyUpdateMessages), secret) // secret derived from DH exchange or hybrid key exchange application_traffic_secret_N+1 = Derive-Secret(sk,"traffic upd 2", application_traffic_secret_N)
The next generation of traffic keys is computed using the HKDF, as defined in [RFC5869], and its two components, HKDF-Extract and HKDF-Expand, as recommended in Appendix F.1.1 of [I-D.ietf-tls-rfc8446bis]. It would also ensure that client_application_traffic_secret_N+1 and sever_application_traffic_secret_N+1 are different. It also uses application_traffic_secret_N to create a binding security property to the prior key.
The step 4 discussed in "Extended Key Update Message" does not look complete to me.
Remove the following line (it does not discuss hybrid key exchange, it only refers to use of ML-KEM): "TLS supports the hybrid key exchange based on the extension defined in {{I-D.connolly-tls-mlkem-key-agreement}}"