Why does TLS 1.3 support two CCM variants?

Question

One of the important improvements introduced in TLS 1.3 is the pruning of the many previously available cipher suites to only five secure options (for symmetric ciphers), that are each supposed to have distinct advantages. For four of these, the advantages seem to be clear:

• TLS_AES_128_GCM_SHA256: faster on systems with hardware support for AES/GMCM.
• TLS_AES_256_GCM_SHA384: bigger numbers for regulatory (or marketing) reasons; resistant to Grover's algorithm.
• TLS_CHACHA20_POLY1305_SHA256: faster in software with no AES acceleration.
• TLS_AES_128_CCM_8_SHA256: useful for embedded devices that just want to reuse an AES circuit for both encryption and authentication; shorter tag.

However, I am still puzzled about the rationale behind the inclusion of TLS_AES_128_CCM_SHA256.

If I understand correctly, CCM with 64-bit authentication tags should be resistant against $2^{64}$ forgery attempts, which is also the maximal amount of messages TLS allows to be encrypted with the same key. So what is the added benefit of also supporting a version with 128-bit tags?

Of course I could be mistaken about CCM_8, and maybe it is not suitable for authenticating $2^{64}$ messages after all. But in that case, why doesn't RFC 8446 mention this in the "Limits on Key Usage" section? What am I missing here?

Answer 1

The rationale goes this way:

• On a "big" system like a PC or a smartphone, ChaCha20+Poly1305 or AES/GCM are very efficient; the latter is fast because the hardware provides dedicated opcodes that implement both AES itself (aesenc, aesenclast on x86 CPU) and the GHASH part of GCM, which is used for the integrity check (pclmulqdq opcode on x86 CPU).

• On much smaller systems (embedded microcontrollers), things are not that easy. Pure software implementations of AES/GCM are quite slow; ChaCha20+Poly1305 may fare somewhat better, but not necessarily as fast as can be hoped for. Note that "speed" can mean "maximum bandwidth", but also battery life: when processing small messages, the cost for encrypting can be expressed in terms of a duration during which the CPU must be powered at its high frequency.

  On that kind of system, you may have an hardware AES implementation, but usually not a an hardware helper for GHASH (because of size constraints on the CPU die, mostly). Thus, CCM works better than GCM on such microcontrollers. This explains the request for supporting some CCM-based cipher suites.

• Constrained systems are usually constrained for everything; computing stuff drains the battery, but so does sending data. Reducing the amount of bytes to send can help, and every byte counts. The normal authentication tag of CCM is 16 bytes. The "CCM_8" cipher suites use tags reduced to 8 bytes, thus saving 8 bytes of overhead, at the expense of a higher probability of forgery.

This is how TLS 1.3 ends up with CCM_8 cipher suites. It's all about performance issues on small embedded systems. Note that MAC can tolerate a relatively high forgery probability because of their "online" nature: when an attacker tries to forge a MAC value, he still have to try it out on an honest receiver for every forgery attempt; if the attacker is talking with small embedded systems, he won't be able to do that many times per second (and each failed attempt implies an error on the receiving system). This contrasts with encryption, where a brute force attack is "offline" (the attacker tries potential decryption keys on his own computers, and can thus do that at a high rate, and quietly).

It is worth pointing out that AES/GCM has a bit of trouble with truncated tags. An authentication tag of $n$ bits cannot have a probability of forgery less than $2^{-n}$, but with GCM, when $n < 128$, it tends to be higher (specifically, successful forgeries leak extra information, making subsequent forgeries easier). As such, tag truncation on GCM is not recommended. CCM, for all its design issues, does not suffer in the same way.