Forward Secrecy

An attacker might record encrypted traffic and only later obtain a server’s long-term authentication key. With the relevant forward-secrecy property, that key alone does not become a universal way to reconstruct completed sessions.

Old session keys, ephemeral private keys or other reconstructing material must not remain available. Capturing those directly can still expose traffic. Forward secrecy is not universal protection against active endpoint control, separately stored plaintext or every cryptographic failure.

References: [1]

Certificate-authenticated TLS 1.3 can derive a shared secret through ephemeral asymmetric exchange and authenticate the handshake using a long-term signature key. Authentication need not make that signing key a decryption key for old application traffic.

The version label alone is insufficient. RFC 9846 distinguishes PSK-only from PSK plus asymmetric exchange, and psk_ke does not provide the stated forward secrecy against long-term-key compromise. Resumption must be evaluated by its actual mode.

References: [1]

TLS 0-RTT early data has weaker forward-secrecy conditions than ordinary 1-RTT data and distinct replay exposure. Properties of a completed new exchange cannot be applied indiscriminately to early requests.

Post-compromise security is different. Once a traffic secret is exposed, deterministic updates alone may remain traceable: RFC 9846 explains that it can yield later TLS traffic secrets. Recovery needs suitable new secret material and protocol exchange rather than assuming forward secrecy already supplies it.

References: [1]