[Nextgrid]

From what I can see this protocol is compatible with TLS 1.3 clients. It makes clients believe perfect forward secrecy is in effect while in fact it isn’t.

The risk isn’t much about internal networks, it’s when this starts leaking onto the open internet.

Also the fact they call themselves “eTLS” to use TLS’ reputation when actually it’s a voluntarily degraded version of TLS.

[kabwj]

There’s no way to guarantee forward secrecy to a client. If regular TLS promises that, the committee is lying and they know it.

[zrm]

There are constructions that provide forward secrecy when both the client and server follow them. This is what TLS aims to provide.

If the server doesn't faithfully implement the protocol, of course it will not provide the expected security guarantees. But then it isn't the committee who is lying, it's the server by claiming to implement TLS and then not.

[zaroth]

Forward secrecy is mostly a myth anyway when the “ephemeral” keys used to generate the session are kept in memory for weeks, months, or years already (e.g. HAProxy)

[Dylan16807]

Sure, if you want to pretend that an easily-fixed bug makes security a myth.

[zaroth]

It doesn't matter how easy the bug is to fix, if 90 out of 100 sites don't fix it. In this case it's less of a bug than it is a thorn, because rotating the keys requires knowing when they can actually expire, which requires state that the process holding the keys usually doesn't carry.

But my point was more along the lines that PFS was never a guaranteed contract with the client, only a possibility offered by certain key exchange protocols, and even then, easy enough to get wrong that most people did.