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

My view is this decision was made because a lot of recent attacks are a version of the Bleichenbacher attack, that depends on the first four bytes of the PKCS padding used in CBC mode. Especially old modes kept for support. POODLE is a downgrade vulnerability. LOGJAM is downgrading TLS to old, export-grade (read NSA-sabotaged) crypto suites.

Bleichenbachers attack depends 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, but the rest was wrong.

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 correctly is impossible to do perfectly, 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.

"Why" is always hard to answer without speculation. In the case of cryptography, our best guides to the future are attacks of the past. In this particular case, simply having the flawed CBC implementation present contributed to the POODLE attack. POODLE was then followed by CRIME, BEAST, and a whole class of attacks that came to be known as padding-oracle attacks.

We may now think everyone knows they should test their padding bytes schemes, but that's only an assumption. Sadly, too many people stop testing once they get the good results they expect, without ensuring there are no side effects in their leftovers.

Now, consider the cost of implementing TLS 1.3. Writing the code is easy. But developers are then going to have to test a combinatoric nightmare of versions, algorithms, key exchanges, etc. And we know that attackers have frequently exploited protocols by combining elements in unexpected and novel ways. Anything they can throw out of the suite makes studying it and testing it orders of magnitude simpler.

Was CBC really to blame, or did it just lead down a path where an unexpected mistake created a vulnerability? The answer is if that's a path we don't need, perhaps it's best to close it entirely.