# Why does TLS 1.3 support two CCM variants?

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?

• Full CCM gives you a better probability of non-forgery even when the full $2^{64}$ messages are used. – SEJPM Nov 8 '18 at 16:08
• Also, CCM is easier to implement than GCM and probably faster if only AES acceleration is available. Also it doesn't have the input size restrictions GCM has. – SEJPM Nov 8 '18 at 16:17
• I think the answer lies simply in the fact that $2^{64}$ is not considered all that large when it comes to crypto. Generally you would try and achieve 128 bits of security, even though 64 bit security is rather a lot when it comes to MAC authentication. Not that I'm for inclusion of a lot of ciphersuites, SHA-384 might as well have been skipped in favor of SHA-512 and personally I would just have kept it to the 64 variant of the CCM authentication tag, as CCM is mainly useful for embedded devices. – Maarten Bodewes Nov 8 '18 at 20:15

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.

• This is a good explanation of the rationale behind the support for CCM_8. But then why is it necessary to support CCM without MAC truncation as well? Is therea use case where CCM_16 is preferable over CCM_8? – AardvarkSoup Dec 13 '18 at 19:24
• There are situations where people want to speed benefit of CCM over GCM (on hardware with AES acceleration, but not GHASH acceleration) but have less stringent bandwidth requirement and prefer the 128-bit tags so that they can claim a blanket "128-bit security" without to get into the subtleties of online/offline attacks in order to explain why a $2^{-64}$ forgery probability is not a big deal. – Thomas Pornin Dec 13 '18 at 20:59
• Ah, that would explain it. I guess the purpose of the CCM ciphersuite without truncation is mostly marketing then... – AardvarkSoup Apr 13 at 21:21