ETS protocol does not provide per-session forward secrecy
1–10 of 39 posts
Re: ETS protocol does not provide per-session forward secrecy
#2Re: ETS protocol does not provide per-session forward secrecy
#3Re: ETS protocol does not provide per-session forward secrecy
#4Can clients detect the use of this, and if detected refuse to connect with a scary warning? That should kill this abomination fairly effectively.
Re: ETS protocol does not provide per-session forward secrecy
#5Re: ETS protocol does not provide per-session forward secrecy
#6Why 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.
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
#7Why 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.
Re: ETS protocol does not provide per-session forward secrecy
#8And 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
#9Why 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
#10Why 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…
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.