[vbernat]

The article and the comments here lack a bit of context. At the time where tickets were starting to be deployed (around 2011), ECDH ciphers were not in use and PFS was therefore quite expensive (and therefore, almost never used). Around the same time, the move from 1024-bit certificates to 2048-bit certificates were making TLS difficult to deploy at scale for everyone except Google.

Session tickets were primarily a mechanism to help to reduce to load of TLS connections. The reduced latency is a happy side-effect. At the time, it was already well-known that this would negatively impact PFS (something I already mention in my own blog article about session tickets in 2011).

Moreover, many seem to build a scenario where session tickets are recovered by an attacker but not the private keys. Usually, session tickets are in memory only and private keys are persisted. This makes those tickets more unlikely to be recovered by anyone unless you get access to a running web server. In this case, you have far more serious trouble than those tickets (even if the attacker still cannot decode past recorded data).

Even today, TLS handshakes are quite expensive, both for the server and the clients. Using session tickets (with rotated keys) still outweigh the downsides of not using them. That's why every major site are using them.