Change:
If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections <del> established using PSKs enjoy forward secrecy.  This improves security for all 0-RTT data and PSK usage when PSK is used without (EC)DHE. </del> <ins> established using PSKs enjoy not only anti-replay protection, but also forward secrecy once all copies of the PSK from the database entry have been deleted.  This mechanism also improves security for PSK usage when PSK is used without (EC)DHE. </ins> Because this mechanism requires sharing the session database between server nodes in environments with multiple distributed servers, it

Discussion:
This is following issue . 0-RTT data may sometimes be forward-secret, and sometimes not. This commit attempts to clarify that in Sections 2.3 and 8.1.
This is great. Thanks so much for writing this up!
"forward secret" as an adjective is wierd.
Presumably because it doesn't indicate in what circumstances it's forward secret (e.g. it could be completely random). Maybe it's more accurate to say "forward secret only under certain circumstances on the server side."
How about this: The protocol does not provide any forward secrecy guarantees for this data. The server's behavior determines what forward secrecy guarantees, if any, are applicable (see {{single-use-tickets}}). This behavior is not communicated to the client as part of the protocol. Therefore, absent out-of-band knowledge of the server's behavior, the client should assume that this data is not forward secret. Thanks Carrick :-) NAME NAME What do you think?
NAME Sounds good to me.
NAME please send me a PR to add your name to the acknowledgements.
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?
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.
Thanks! It's much clearer to me now.
This seems okay. I don't get excited by having the initial statement be "not necessarily forward secret" but can't put my finger on exactly why, and I don't have an alternative suggestion, so I won't object to this.