# TLS 1.3 - Why have no encrypt-then-MAC modes been specified?

I have been scratching my head for a while why TLS 1.3 does not include any encrypt-then-MAC (EtM) modes. All the previous problems in TLS have been caused by MAC then and encrypt. Whereas encrypt then MAC avoids all the issues caused by padding in the past since a receiver can verify the message integrity without having to first decrypt the message and then handle mangled padding correctly.

What is annoying about this to me is there are quite a few micro-controllers that have built-in AES hardware acceleration. However, something like a carry-less multiply for GCM really only exists on server and desktop CPUs.

While there is ChaCha20-Poly1305 using it instead means you forgo using AES hardware on micro-controllers. While ChaCha20 works well with 32bit micros it's still gonna use more power than built-in AES hardware and likely be slower depending on the micro. Also, Poly1305 requires doing some big-num modular arithmetic compared to a lot of hash functions.

I am just scratching my head since there is nothing wrong with EtM. I even found a draft IETF AES-CBC-HMAC where that performs EtM. However, it never made it past a draft which just strikes me as odd.

Edit: Since CCM Cipher suites were mentioned. while running AES in CTR mode does avoid padding oracles. It is not on of the mandatory cipher-suite or one of the SHOULD implement suites. See: Mandatory-to-Implement Cipher Suites So one basically can't take advantage of AES hardware on a micro without also having GCM. (i.g. lots of servers disable CCM by default and neither Firefox nor Chrome enable CCM). So again still seems odd there is nothing in-between here, and I don't really see any good reason why, and an EtM mode seems like a decent candidate, but one was never even added to the standard.

For embedded devices there is CCM mode, which is basically a secure way of performing AES-CBC-MAC + AES-CTR in a (needlessly complex, but rather efficient) packet mode. Note that this is basically MAC-then-encrypt, but as part of an overall secure mode; padding oracles attacks are certainly not applicable as counter mode doesn't require padding.

The ciphersuites available are:

• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256 (as defined in RFC 6655)

The latter also has a more efficient authentication tag (with regards to size, not computational effort) of 8 bytes / 64 bits, which should be enough.

So I guess they didn't think that another algorithm is necessary, also because there are few embedded systems that have SHA-1 or SHA-256 acceleration.

Notes:

• The hash at the end of the ciphersuite is only used for session key derivation and such (the PRF in TLS), so it isn't used for each message.
• AES in CTR mode and in CBC-MAC is only used in the forward / encryption mode, so you don't need hardware support for the decryption operation.
• Is there a specific reason to write AES-CBC-MAC + AES-CTR instead of AES-CTR + AES-CBC-MAC other than indicating the MAC is performed before encryption? Dec 22, 2021 at 19:15
• @kelalaka No, I thought it was less confusing this way. Dec 22, 2021 at 19:29
• Maybe adding $$c = \big(\operatorname{AES-CTR}(m)\|(\operatorname{AES-CTR}(m_0) \oplus \operatorname{AES-CBC-MAC}\big(Nonce\mathbin\|Associated Data \mathbin\|m) \big)\big)$$ will make it more clear or unclear. Dec 22, 2021 at 19:49
• Sure there is CCM. It's fine for instance if you control the server your device is talking to for like api request ect... One other thing that I have noticed though is other servers seem have it disabled often. Also chrome and firefox don't enable that cipher suite again limiting options. Dec 23, 2021 at 0:49
• Sure, but it is unclear how e.g. CBC + HMAC would fare as well. It would not likely be a required cipher suite, so it would be optional as well. That CCM is not EtM is kind of beside the point ... as long as it is secure. It is unlikely that somebody would implement it as decrypt, use and then verify - even if that's possible. Dec 23, 2021 at 1:32