Live data from Hacker News

ETS protocol does not provide per-session forward secrecy

nvd.nist.gov

1–10 of 39 posts

Re: ETS protocol does not provide per-session forward secrecy

#6
post #5

Why do people hate eTLS so much? What do you care what enterprises do within their own networks? They have their requirements and they’ll have to implement them one way or the other.

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.

Re: ETS protocol does not provide per-session forward secrecy

#7
post #5

Why do people hate eTLS so much? What do you care what enterprises do within their own networks? They have their requirements and they’ll have to implement them one way or the other.

Why wouldn't they? That group is trying to standardize a protocol that effectively negates a whole lot of progress and even tried to piggy back on the TLS name. Their stated requirements boil down to snake oil and laziness. If companies or groups thereof want to use security measures that aren't on par with the state of the art and intentionally ignore recent learnings, they of course still have that capability but I don't see why they should be given an opportunity to hide that fact behind a known bad standard. That'd only lead others to be forced to use a broken protocol for reasons like compliance.

Re: ETS protocol does not provide per-session forward secrecy

#8
I don't get the complaints. As far as I understood (and ietf appears to agree), eTLS is not a protocol, it is a (server-side) implementation variant of TLS.

And it is a universal construction: For any cryptographic protocol, one party can replace its random number generator by a deterministic CSPRNG and store or leak seeds. This is undetectable from outside. There you go, backdoor for later reversal of forward secrecy: Forward secrecy is obtained in the moment you erase from memory the internal state of your CSPRNG, and the server can just not do that, without violating any protocol assumptions.

Specifying how to implement this in practice is worthwhile; it is not a weakening or violation of TLS, instead it is an interesting description of inherent properties of TLS.

The naming (eTLS) might be unfortunate. Better to just make it an RFC on "Cryptographic backdoors for TLS".

Re: ETS protocol does not provide per-session forward secrecy

#9
post #6
post #5

Why do people hate eTLS so much? What do you care what enterprises do within their own networks? They have their requirements and they’ll have to implement them one way or the other.

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.

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

Re: ETS protocol does not provide per-session forward secrecy

#10
post #5

Why do people hate eTLS so much? What do you care what enterprises do within their own networks? They have their requirements and they’ll have to implement them one way or the other.

Why wouldn't they? That group is trying to standardize a protocol that effectively negates a whole lot of progress and even tried to piggy back on the TLS name. Their stated requirements boil down to snake oil and laziness. If companies or groups thereof want to use security measures that aren't on par with the state of the art and intentionally ignore recent learnings, they of course still have that capability but I…

> Their stated requirements boil down to snake oil and laziness.

Without knowing the internal structure of these particular organizations at all, that's quite a bold claim. If a company has a half million employees and their technology supports billions/trillions of dollars of transactions, it's quite likely that "laziness" has nothing to do with upgrading the entirety of the IPS & DLP products they support, to say nothing of solutions on the client or server side. They can't just edit some config and make all their technology magically support a new protocol that is explicitly designed to stymie their efforts.

Post reply on HN