On 22/07/2025 00:23, Eric Rescorla wrote:
While the built-in KeyUpdate mechanism allows traffic
keys to be refreshed during a session, it does not introduce new
forward-secret key material. [...]
To address this, this specification defines an extended key update
mechanism that performs a fresh Diffie-Hellman exchange within an
active session, thereby re-establishing forward secrecy beyond the
initial handshake.
I'm not sure what it means to "reestablish forward secrecy". The TLS
1.3 KeyUpdate mechanism provides forward secrecy, in that a key
compromise at epoch N+1 does not threaten data transmitted
under key N. What this mechanism provides is post-compromise security,
which is to say protection for data protected under key N+1 even
if key N is compromised.
To be clear, I'm not saying that this extension doesn't have value,
merely that that value is not about FS.
I gave very similar feedback on-list in March 2024:
I think there is some confusion about what forward secrecy is. Forward
secrecy means that compromise in the future will not enable the
decryption of past messages. The existing KeyUpdate mechanism in
TLS1.3 achieves forward secrecy by ratcheting forwards the used keys
and throwing away the old ones.
Introduction:
If a traffic secret (referred as application_traffic_secret_N) has
been compromised, an attacker can passively eavesdrop on all future
data sent on the connection, including data encrypted with
application_traffic_secret_N+1, application_traffic_secret_N+2, etc.
This is not forward secrecy but post-compromise security (PCS) [1]
(sometimes called Backwards Secrecy as it is the complement of Forward
Secrecy).
I'm a bit surprised this hasn't been fixed yet.
I also agree with Ekr's other suggestions around simplifying the state
machine.
Best,
Dennis
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
