The good news: TLS 1.3 is available, and the protocol, which powers HTTPS and many other encrypted communications, is better and more secure than its predecessors (including SSL).

The bad news: Thanks to a financial industry group called BITS, there’s a look-alike protocol brewing called ETS (or eTLS) that intentionally disables important security measures in TLS 1.3. If someone suggests that you should deploy ETS instead of TLS 1.3, they are selling you snake oil and you should run in the other direction as fast as you can.

ETS vs. TLS / SSL

ETS removes forward secrecy, a feature that is so widely used and valued in TLS 1.2 that TLS 1.3 made it mandatory. This removal invisibly undermines security and has the potential to seriously worsen data breaches. As the ETS / eTLS spec says: "eTLS does not provide per-session forward secrecy. Knowledge of a given static Diffie-Hellman private key can be used to decrypt all sessions encrypted with that key."

In earlier versions of TLS and SSL, forward secrecy was an optional feature. If enabled, it ensured that intercepted communications couldn’t be retrospectively decrypted, even by someone who later got a copy of the server’s private key. This remarkable property is so valuable for security that the Internet Engineering Task Force (IETF), which develops Internet standards including TLS, decided that TLS 1.3 would only offer algorithms that provide forward secrecy. The post-facto decryption weakness in TLS 1.2 and earlier versions is now considered a bug. It’s a product of its time that was produced by a number of factors, like government pressure not to implement stronger algorithms, a cloud of patent-related uncertainty around elliptic curve algorithms, and processor speed in the early 2000’s.

Nowadays, it just makes plain sense to use forward secrecy for all TLS connections. Unfortunately, during the long tenure of TLS 1.2, some companies, mostly banks, came to rely on its specific weaknesses. Late in the TLS 1.3 process, BITS came forward on behalf of these companies and said their members “depend upon the ability to decrypt TLS traffic to implement data loss protection, intrusion detection and prevention, malware detection, packet capture and analysis, and DDoS mitigation.” In other words, BITS members send a copy of all encrypted traffic somewhere else for monitoring. The monitoring devices have a copy of all private keys, and so can decrypt all that traffic. They’d like TLS 1.3 to offer algorithms that disable forward secrecy so they can keep doing this decryption.

But there’s a real harm that comes from weakening a critical protocol to provide easier in-datacenter monitoring for a small handful of organizations. Public-facing web servers might also implement the proposed weaker algorithms, either intentionally or accidentally, and this would expose billions of people’s data to easier snooping. Plus, this isn’t even a good way to do in-datacenter monitoring–with control of the servers, an organization can log data at their servers rather than relying on post-hoc decryption. Server-side logging can also redact sensitive data like plaintext passwords that should never be retained.

In response to these objections, some IETF participants produced a modest proposal: By tweaking some parameters, they could make a TLS 1.3 server look like it was providing forward secrecy, but actually not provide it. This proposal, mentioned earlier and called “Static Diffie-Hellman,” would misuse a number in the handshake that is supposed to be random and discarded after each handshake. Instead of randomly generating that number (the Diffie-Hellman private key), a server using this technique would use the same number for all connections, and make sure to share a copy of it with the devices doing decryption. This would only require changes to servers, not clients, and would look just like the secure version of TLS 1.3.

After much discussion, IETF decided not to standardize this modest proposal. Its risks were too great. So BITS took it to another standards organization, ETSI, which was more willing to play ball. ETSI has been working on its weakened variant since 2017, and in October 2018 released a document calling their proposal eTLS. They even submitted public comment asking NIST to delay publication of new guidelines on using TLS 1.3 and recommend eTLS instead.

“Enterprise” Transport Security Tries to Use TLS’ Good Name

Meanwhile, the IETF caught wind of this and strenuously objected to the misleading use of the name TLS in “eTLS:” “Our foremost concern remains the use of a name that implies the aegis of Transport Layer Security (TLS), a well-known protocol which has been developed by the IETF for over twenty years.” ETSI backed down, and the next revision of their weakened variant will be called “ETS” instead. Instead of thinking of this as “Enterprise Transport Security,” which the creators say the acronym stands for, you should think of it as “Extra Terrible Security.”

Internet security as a whole is greatly improved by forward secrecy. It’s indefensible to make it worse in the name of protecting a few banks from having to update their legacy decrypt systems. Decryption makes networks less secure, and anyone who tells you differently is selling something (probably a decryption middlebox). Don’t use ETS, don’t implement it, and don’t standardize it.