39
$\begingroup$

I don't quite understand why AES CBC was removed in TLS1.3.

From what I know CBC is the most secure Mode of operation for the AES block cipher (if you can say it like that).

It only needs a TRND IV and has not been broken. If you pair it with a decent HMAC I guess It's at least as secure and AES-GCM.

So why is AES-GCM preferred and the CBC support was removed?

Improve this question
$\endgroup$
2
  • 12
    $\begingroup$ Do you have any source for your claim that CBC is the most secure mode? $\endgroup$
    – axapaxa
    Oct 26, 2017 at 15:28
  • 2
    $\begingroup$ Basically, SSL/TLS screwed up their protocol by using a MAC-then-ENCRYPT approach and by using knowable IVs, both of which are particularly problematic for CBC mode. They addressed the latter flaw in v1.1, but rather than fix the former issue (e.g. - in the new version), they decided to just quietly move on instead. In the process they gave a bad name to CBC mode when the infamy should rightly belong to TLS and its implementations. $\endgroup$
    – jschultz410
    Feb 15, 2018 at 20:26

3 Answers 3

Reset to default
49
$\begingroup$

Short: CBC mode in context of TLS protocol has had security issues, and would have had to be reworked.

AES-CBC mode combined with decent HMAC can be as secure as AES-GCM. However, combining the cipher and MAC securely has been in practice found to be much easier said than done. Also, padding that is required by AES-CBC mode complicates things.

In particular, within the history of the SSL and TLS protocols, there is a long history of security vulnerabilities resulting from misuse of CBC mode or within combination of CBC and MAC, such as BEAST and Lucky13.

After the Lucky13 attack (a timing oracle caused by MAC-then-encrypt), it was thought that TLS should change ordering of the operations. Changing order of the operations would have affected the backwards compatibility with previous implementations so it was after all thought that it is more practical to switch to authenticated encryption only.

In addition to security aspects, there are some other practical benefits of AES-GCM over AES-CBC and HMAC:

  • On most platforms with hardware acceleration or AES-NI instructions, AES-GCM is many times faster than AES-CBC with HMAC. This is because AES-GCM is designed to be more parallelizable.
  • Generation of random bits is relatively slow. This is also where AES-GCM excels. Random bits are more seldomly needed than with AES-CBC (in TLS 1.1+.)
  • AES-GCM in average does not extend the size of the message as much as equivalent combination of AES-CBC, HMAC and padding.
Improve this answer
$\endgroup$
8
  • 1
    $\begingroup$ Are you aware of any implementation TLS actually leveraging the parallelization of AES-GCM for a single messages ? Do you know why ciphertext stealing has never been considered as a solution to CBC padding issues ? $\endgroup$
    – Ruggero
    Oct 27, 2017 at 9:59
  • $\begingroup$ @Ruggero: It is actually very common to use parallelization within one CPU core for single messages (i.e. to compute multiple blocks in parallel). I'm not aware if some software implementations used multiple cores for processing parts of the same message. Ciphertext stealing helps with padding but it does not remove the other downsides of CBC mode. Also it could add more complexity: Ciphertext stealing can only be used if data is larger than single cipher block (which should not be of a concern in TLS). It appears CBC-CS would rarely offer advantages over GCM, but require a lot of changes. $\endgroup$
    – user4982
    Oct 27, 2017 at 15:45
  • $\begingroup$ I understand for CBC-CS, thanks. For parallelization I'm not following, are you referring to SIMD ? Can you please point to any TLS implementation doing this parallelization ? $\endgroup$
    – Ruggero
    Oct 30, 2017 at 8:39
  • $\begingroup$ @Ruggero: Parallelizable block cipher modes of operation allow many blocks to be processed in parallel (i.e. there is no processing dependency on previous block cipher operations making the process sequential). This parallel processing allows speed up when there is a lot of data, and either multiple execution units or AES computation is parallelized/pipelined. I did not refer to SIMD, but in some cases realization of parallelization may involve usage of SIMD. On typical x86 processors with AES-NI, all typical TLS software, for example OpenSSL, will take advantage of pipelined implementation. $\endgroup$
    – user4982
    Oct 31, 2017 at 16:37
  • 2
    $\begingroup$ @Ruggero: The comments are not meant for long discussions. You can e.g. add a new question on benefits of parallelizable block cipher modes of operation. Intel has a document Intel Advanced Encryption Standard (AES) New Instructions Set which describes page 48 onwards how parallelizable modes of operation are used for performance on Intel platforms. Similar benefits can be achieved also when using ARMv8-a crypto extension or when using some dedicated hardware implementations. $\endgroup$
    – user4982
    Nov 2, 2017 at 16:37
17
$\begingroup$

TLS 1.3 is a reboot of the TLS protocol which focused on up to date cryptography rather than backwards compatibility.

Now CBC is not as secure as you make it to be, and the way that it was used in TLS made it particularly vulnerable. To note: in TLS the HMAC authentication tag was created over the plaintext rather than the ciphertext. This made TLS vulnerable to CBC padding oracle attacks. As you've already noted, it requires an IV that cannot be predicted by an attacker and the cipher fails if this requirement isn't met.

These kind of attacks are easily avoided by AEAD (authenticated) ciphers such as GCM. These modes come with security proofs (build on top of a secure block cipher / MAC algorithm). This makes them less likely to be vulnerable to the previous attacks on CBC mode. As they tend to be more efficient as well there it is simply no reason to avoid an already specified AEAD cipher such as GCM. GCM is build on top of CTR mode, so the cipher doesn't require padding, removing one of the possible attack vectors.

There has actually been a try to make CBC then HMAC an official AEAD cipher in this RFC proposal. This AEAD cipher never made it past the draft stage however. It would still require the special IV and it would be less efficient; there is no reason to include it if your goal is maximum efficiency and security for TLS 1.3.

Improve this answer
$\endgroup$
2
  • 6
    $\begingroup$ ITYM 1.3 was (or really was proposed) as a reboot. EtM as an extension to TLS and DTLS 1.2 made it to standard as 7366 (in Sep. 2014) but I don't know any implementation of it other than gnuTLS. (Although there is an erratum that indicates there were multiple implementations somewhere.) $\endgroup$
    – dave_thompson_085
    Oct 27, 2017 at 2:35
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$
    – Maarten Bodewes ♦
    Mar 27, 2019 at 18:22
10
$\begingroup$

from what I know CBC is the most secure Mode of operation for the AES block cipher

I'm not exactly sure why you say this; however, there has been a couple of practical problems with CBC mode in the past:

  • Padding Oracle attacks; as originally designed in SSL (and carried into TLS 1.2), the way TLS implements CBC mode (with the padding and the HMAC) is prone to various decryption oracle attacks (where the attacker modifies the TLS record, and watches how the decryptor reacts). It is possible to design a TLS decryptor to react uniformly on a bad record; it is considerably harder to do correctly than you'd expect.

  • IV selection; yes, if you select the IVs correctly, you're safe; however this does leave open the possibility that an implementation doesn't select their IVs correctly.

Now, they could have reworked how CBC and HMAC works, e.g. HMAC the ciphertext instead, use deterministic but unpredictable (to someone who doesn't know the keys) IVs; they declined to do so.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.