Why did TLS 1.3 drop AES-CBC?

Question

I was watching this video about TLS 1.3: "Deploying TLS 1.3: the great, the good and the bad (33c3)" and was somewhat surprised to see that in their effort to provide

"fewer, better choices"

they dropped AES-CBC as a supported block cipher mode.

The video lists a number of attacks (Lucky13, POODLE and others), that to my untrained eye seem to be implementation issues. I understand that it is better to have a mode that doesn't encourage such implementation issues, but was that all it took to deprecate this entire cipher mode?

While this book is somewhat dated (2010), Cryptography Engineering it recommends AES-CBC using a randomly generated IV as the best option.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

"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.

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, reducing the attack surface.

Answer 5

I believe that AES-CBC is still good, provided that you use it properly. Because TLS uses mac-then-encrypt, it is a dangerous field that allows multiple vulnerabilities. Current TLS implementations contain multiple hacks to implement it (hopefully) securely. For example, when a peer sees invalid padding, it just destroys some data (probably through xor) in order to break MAC check a while later. The whole process must take the same amount of time regardless of the error type (bad padding or MAC error) and error position in order not to leak any information in timing.

Removing CBC is one way how to fix it for the new protocol version. Using encrypt-then-mac would be another way, but this would AFAIK change structures of TLS, which could cause implementation difficulties, I guess. Changing the protocol structures could be painful in code that supports multiple TLS versions. Since there are other good modes, it is probably easier to switch to them than to change the protocol structures.

Answer 6

It boils down to Moxie Marlinspike's Cryptographic Doom Principle, which states:

If you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.

With the AES-CBC as implemented in TLS 1.2, an HMAC of the plaintext (and header information) is taken. Then, this HMAC is concatenated with the plaintext, padded to the necessary length, then encrypted with AES-CBC, and sent over the wire. See section 6.2.3.2 of RFC5246 for more information.

This is the Authenticate then encrypt case, as described in the blog post referenced above by Moxie: The sender computes a MAC of the plaintext, then encrypts both the plaintext and the MAC. Ek1(P || MACk2(P)). This is susceptible to Vaudenay's Attack, as described in the blog post.