Why does TLS do Authenticate-then-Encrypt instead of Encrypt-then-Authenticate?

Question

Encrypt-then-Authenticate (EtA) seems to generally be considered the better option, compared to Authenticate-then-Encrypt (AtE) (see this Crypto.SE question, for example). The people writing the RFC for TLS 1.2 seem to have been aware of this, but have chosen to use AtE anyway.

Is there a reason why this is the case? Is this a case of "Someone standardized something at some point and now we're stuck with it for backwards compatibility, even though we know it's bad", or is there a good reason why AtE is better for TLS?

Clarification, because this wasn't very well-written originally: I am referring to the actual encrypted channel after the handshake has finished. It's clear that you have to authenticate the server and perform a key exchange before you can perform any useful form of encryption.

Answer 1

SSL was designed long ago when encrypt-then-MAC wasn't that popular yet. Even TLS 1.2, published in 2008, is pretty old by now, and while encrypt-then-MAC was preferred by then, the practical risks were underestimated for a long time. Padding oracles attacks became well known after several high profile attacks in 2010.

With stream ciphers, MAC-then-encrypt is safe and easy to implement correctly. With CBC it's trickier, but technically the way it's used in TLS is provably secure if you ensure that the attacker doesn't learn anything about the cause of a detected manipulation (invalid padding vs incorrect MAC etc).

The choice of MAC-then-encrypt has lead to several weaknesses over the history of SSL and TLS, including POODLE and Lucky 13.

• Lucky 13 was a timing attack, which gave an attacker information about why decryption failed, invalidating the proof.
• POODLE was an attack against SSL 3.0 (and some careless TLS implementations) which didn't have as strict padding validation requirements as newer versions of TLS.

In response to these attacks TLS implementations were carefully written to avoid side channel attacks, working around these weaknesses.

There is a draft TLS extension (Encrypt-then-MAC for TLS and DTLS draft-gutmann-tls-encrypt-then-mac) to use encrypt-then-MAC, but it didn't gain much traction and still hasn't been finalized.

TLS 1.3 will only support AEAD suites, where each suite is responsible for ensuring both confidentiality and authenticity, instead of combining MAC and encryption at the protocol level. So in TLS 1.3 this problem will finally be fixed.

Answer 2

if you do encrypt first you have to have pre-shared secret keys between client and servers? once master secret is generated then Record protocol job is to encrypt/decrypt.