Why did TLS 1.3 drop AES-CBC?

The problem here is not so much with CBC, but with alternatives that are easier to implement safely, without losing mathematical security.In fact, AES-CBC turned out to be notoriously difficult to implement correctly. I recall that older implementations of transport layer security don't have cryptographically secure initialization vectors, which are a must-have for CBC mode

A lot of recent attacks are padding oracle attacks, like the Bleichenbacher attack. These especially depend on old modes kept for support. POODLE is a downgrade vulnerability. LOGJAM is downgrading TLS to old, export-grade (read NSA-sabotaged) crypto suites.

For CBC mode, there is the Vaudenay attack. These attacks depend on the server explicitly saying "invalid padding", thereby leaking 1 bit of information on each transaction. Error messages were removed, but the problem of timing remained. The server still used more time before responding if the padding was valid.

In response they were forced to come up with the peculiar workaround of generating a dummy key, and using that for decryption so it would fail in another part of the implementation. In every implementation. So they decided to no longer force that on developers by supporting it in the specs.

Cryptography is a very broad field, and a specialty on its own. History had learned through uncomfortable experience, that doing it perfectly is almost never guaranteed, even for the best in the field. For example MD5, created by Ron Rivest, co-inventor (and part-namesake) of RSA was widely used, then broken in 2013 . Its collision resistance was circumvented in 2^18 time, less than a second on a desktop computer for 128 bit hashes.

CBC is a good mode for encryption if implemented correctly. In one short sentence, I've pointed out two defects of CBC.

• CBC is an encryption mode only: it provides confidentiality, but not authenticity or integrity. You need to authenticate the data separately. It can be done, of course, and that was the only way to do it before TLS 1.2. But it's hard to get right, which is why authenticated encryption modes are recommended. TLS 1.3 pushes GCM instead of CBC + HMAC.
• CBC is hard to implement correctly. There's the issue of how to combine it with a MAC that I already mentioned. Another issue is to not leak information through padding errors. The IV really must be random; an IV that is influenced by an adversary is insecure and is at least a BEAST.

If it's so hard to implement correctly, it's best not allowed by the protocol. Cryptography design is slowly moving towards from having a few well-studied, flexible primitives to having a few well-studied, robust primitives, because in practice the problem is less that people can't do what they want, but more that they do things that work in the nominal case but fall down to attacks.

Basically, Lucky13 happened, and the results were very bad: Amazon s2n thought they fixed it, but turns out they didn't. OpenSSL introduced a much worse vulnerability when they tried to fix it. Google's Adam Langley, possibly the best TLS implementer in the world, chose to not implement the fix in the Go standard library's TLS implementation and recommended people don't support CBC cipher suites if they're worried.

The correct implementation of TLS CBC ciphersuites is much too difficult.

Implementations thought fully patched and secure are discovered to be insecure as variations on the attack improve.

People knew there must be more issues than those listed above, because history taught us that whenever a person thinks of a new stupid thing that a bad TLS implementer might do wrong (like repeating nonces or checking only a single byte of the MAC) and writes a scanner that can check for this wrongness at scale, they inevitably find some implementations that indeed do it wrong and yet manage to get deployed in production, often at Fortune 500 companies.

This as-yet unpublished paper tells of some of the newest round: https://github.com/RUB-NDS/TLS-Padding-Oracles

Nobody who knows about the qualify of implementation of TLS by the smaller players (e.g. cavium, citrix, F5, wolfSSL and mbedTLS) can say that you can rely on them to do it correctly. An alternative exists which is more performant and is much easier to implement correctly, so the correct thing to do is to drop support.