Not clear why 0-RTT doesn't provide perfect forward secrecy

[cbartle891]

Section 2.3 states that "This [0-RTT] data is not forward secret, as it is encrypted solely under keys derived using the offered PSK."

However, Section 8.1 states "If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections established using PSKs enjoy forward secrecy. This improves security for all 0-RTT data."

What does "improves security" mean here? Does it mean that the 0-RTT data is forward secret in this case? If not, why not?

[kaduk]

Forward secrecy is something of a relative property; a given connection X gains forward secrecy with respect to future compromise of entity Y when secret Z is discarded. There are further subtleties, such as if X is still active when Y is compromised then X might still actually be compromised even if Z has already been discarded, but considering all three of X, Y, and Z are necessary to make statements about forward secrecy with any precision.
The thing that we typically mean these days when we talk about "forward secrecy" without further precision is that an ephemeral (e.g., (EC)DH) key exchange mechanism is used, and we're implicitly picking one endpoint X as the subject of discussion, so that Y is the communications peer and Z is the peer's ephemeral DH value. This requires some level of trust in the peer, since a malicious peer could fail to destroy Z or just retain the data in question in some other form.

0-RTT data is protected by a PSK associated with a session ticket, and when the server is using stateless session tickets, the PSK itself is encrypted to the server using the STEK. So the only forward secrecy available to such 0-RTT data is when the STEK is discarded, which we typically recommend to be on an hours to days timescale (but could in principle be much longer, and there are no doubt many sites that essentially never rotate their STEK); given the lack of knowledge of the peer/server behavior, clients should not assume that they have any forward secrecy guarantee for 0-RTT data they send in this case.
When tickets are not stateless but rather are database keys, the server knowledge of the PSK used to protect the 0-RTT data is tied to the database entry for the ticket, and so the PSK can be discarded sooner than in the stateless-ticket case; in the single-use ticket case the server's copy of the PSK is expected to be destroyed when the resumed session is established, which would provide a similar timescale of forward secrecy for the client that a typical ECDH exchange would provide. But the client still has little visibility into what strategy the server is using, and might be ill-advised to place much confidence in the forward secrecy of its offered 0-RTT data, absent out-of-band knowledge of the server's behavior.

[cbartle891]

Thanks! It's much clearer to me now.