[zaroth]

Gives up the property before it begins even. But I completely agree with you. I would go as far to say a connection does not have PFS if you are sending the DH session key encrypted only by a [geographically replicated] static key before the session starts. You are literally destroying the entire purpose of the DH handshake in doing so.

I always assumed the STEK-encrypted session key was sent inside the established TLS PFS stream. To send it outside the stream is mind-numbingly insane!

Browsers should not report connections as having PFS if tickets are enabled in TLS 1.2. This is like NSA slide "PFS added and removed here :-)"

[tptacek]

You're clearly not destroying the entire purpose of the DH handshake, because the STEK is rotated and so the time window of compromise is limited to by the rotation interval. Even with poorly rotated ticket keys, you're still better off with a PFS suite than without it --- without the DH, every client has an unlimited window of exposure if the server's private key is compromised.

[zaroth]

True, it does not destroy the entire purpose if and when the STEK is securely and properly rotated. But to call this PFS stretches the truth in ways that boring crypto never does.

The number of real-world cases where PFS is reduced exactly to the non-PFS state by the existence of session tickets with fixed STEKs is not only non-zero, but rather I would venture a guess it is staggeringly large.

E.g. Configuring Session Tickets [1]

While Apache offers the SSLSessionTicketKeyFile directive to specify a key file that should contain 48 random bytes, it is recommended to not specify one at all. Apache will simply generate a random key on startup and use that to encrypt session tickets for as long as it is running.

The good thing about this is that the session ticket key will not touch persistent storage, the bad thing is that it will never be rotated. Generated once on startup it is only discarded when Apache restarts. For most of the servers out there that means they use the same key for months, if not years.

To provide forward secrecy we need to rotate the session ticket key about daily and current Apache versions provide no way of doing that. The only way to achieve that might be use a cron job to gracefully restart Apache daily to ensure a new key is generated. That does not sound like a real solution though and nothing ensures the old key is properly overridden.

...

Nginx, too, provides no way to automatically rotate keys. Reloading its configuration daily using a cron job might work but does not come close to a real solution either.

...

HAproxy does not allow configuring session ticket parameters. It implicitly supports this feature because OpenSSL enables it by default. HAproxy will thus always generate a session ticket key on startup and use it to encrypt tickets for the whole lifetime of the process.

[1] - https://timtaubert.de/blog/2014/11/the-sad-state-of-server-s...

Note that's from 2014 -- has it changed since then?

[tptacek]

The 'P' in 'PFS' has always stretched the truth, which is why a lot of practitioners elide it.

Even if you never rotate STEKs and never reset systems to get a new STEK accidentally, the DH handshake is still providing forward secrecy value for clients who don't do session tickets.

[zaroth]

Do such clients actually exist in mainstream usage? The one crypto bug which you are actually protected from by using IE on Win7!

[tptacek]

I don't know, but the cost that session tickets are saving are almost entirely an externality to clients, and the privacy benefit of not honoring tickets isn't, so there would seem to be some value to a Chrome extension that busted that cache.

[zaroth]

Yeah but it's not the client sending the resumption ticket but sending the capability in the ClientHello which exposes the session key under a possibly fixed key. So you can't fix this by busting the client cache I think. You need the capability flag off.

Even so could an active adversary turn on the capability in the ClientHello and still get a chance to see the STEK encrypted session key even against legacy (or intentionally ticket-disabled) clients? This I don't know - would a client just drop the ticket message and proceed or would it abort? But at least it would have to be an active attacker.