TLS AES_XXX_CCM mode of operation is encrypt-then-mac or mac-then-encrypt?

Question

There are number of definitions completely confusing me. in https://en.wikipedia.org/wiki/CCM_mode we have

"As the name suggests, CCM mode combines the well known CBC-MAC with the well known counter mode of encryption. These two primitives are applied in an "authenticate-then-encrypt" manner, that is, CBC-MAC is first computed on the message to obtain a tag t; the message and the tag are then encrypted using counter mode. One key insight is that the same encryption key can be used for both, provided that the counter values used in the encryption do not collide with the (pre-)initialization vector used in the authentication."

again in NIST 800-38C specification and RFC6655 we have

"In generation-encryption, cipher block chaining is applied to the payload, the associated data, and the nonce to generate a message authentication code (MAC); then, counter mode encryption is applied to the MAC and the payload to transform them into an unreadable form, called theciphertext"

but RFC7366 states than TLS should follow encrypt-then-mac policy

Answer 1

Given a specific block cipher such as AES, CCM is a specific AEAD scheme: authenticated encryption with associated data, with IND-CCA3 security, loosely meaning it resists eavesdropping and forgery simultaneously.

Encrypt-then-MAC is a generic way to compose an AEAD scheme out of a cipher and a MAC. It always works, in the sense that if the cipher has the standard IND-CPA security expected of it, loosely meaning it resists eavesdropping, and the MAC has the standard UF-CMA security expected of it, loosely meaning it resists forgery, then the encrypt-then-MAC composition has the standard IND-CCA3 security expected of it.

MAC-then-encrypt is another generic way to compose an AEAD scheme out of a cipher and a MAC. But it doesn't always work: there exist IND-CPA ciphers and UF-CMA MACs whose MAC-then-encrypt composition is not IND-CCA3. And it has very sharp edges: some ciphers, such as AES in CBC mode, reject certain messages on decryption due to padding, but the MAC rejects them differently, and the difference reveals information about the plaintexts of messages. This led to the Lucky 13 attack on TLS.

However, while MAC-then-encrypt doesn't always work, it sometimes works, and in the specific case of AES-CCM, which is a MAC-then-encrypt composition of the cipher AES-CTR and a length-tagged variant of the MAC AES-CBC-MAC, it turns out to have IND-CCA3 security and fewer sharp edges. (Safety of randomly chosen nonces, and reuse of nonces, are left as a story for another day.)

Traditionally TLS used a generic MAC-then-encrypt composition for a cipher and a MAC negotiated independently between the server and the client. Eventually the TLS designers realized this was a mistake, and the IETF adopted two remedies for TLS 1.2:

1. RFC 5246 ‘TLS 1.2’, §6.2.3.3 ‘AEAD Ciphers’: Let the server and client negotiate a specific AEAD scheme, such as AES-GCM or AES-CCM.
2. RFC 7366 ‘Encrypt-then-MAC for TLS and DTLS’: Let the server and client negotiate cipher and MAC independently as before, and also let them negotiate the use of encrypt-then-MAC composition instead of MAC-then-encrypt composition.

In TLS 1.3, RFC 8446, all cipher suites are AEAD; there is no generic composition at the layer of the TLS protocol, making the protocol substantially simpler.