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.