[TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Colm MacCárthaigh <[e-mail]>]

This has been bugging me for a long time and I've talked to some here about
it in person, but this report;

https://www.teamupturn.com/static/reports/2016/what-isps-can-see/files/Upturn%20-%20What%20ISPs%20Can%20See%20v.1.0.pdf

provokes me to bring it up. Here's the crux of it; is it really a security
win to recommend the AEAD cipher suites for TLS 1.2 users?

The AEAD cipher suites as-implemented are byte-for-byte mappable to
response sizes, with no padding for any kind of length hiding. This makes
passive size analysis attacks quite a lot easier than they could be (a
quick sample of wikipedia page sizes suggests that even 16 byte blocks
raise the difficulty by orders of magnitude). The search hints attack
outline in the paper may not even work with 16-byte padding. I want to
emphasize that the attack here is passive, undetectable to servers or
clients, and realistic - it's likely happening today.

On the other side of the trade-off is that the AEAD mode ciphers are not
susceptible to mac-then-encrypt issues, such as Lucky13. Some time ago I
wrote up some detail on the Lucky13 attack:
https://blogs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6/s2n-and-Lucky-13
, and my take here is that the scenario is so unrealistic that the attack
is simply impractical against TLS - even unmitigated. In any event, TLS CBC
implementations have been mitigated and patched. Here I also want to
emphasize that the attack is active - it generates lots of noisy signals -
and may never have happened.

Is it wise to make the real-world attack cost less, to mitigate the
theoretical one? I also think AEAD mode is awesome: it's how crypto should
be used, and want to give it a strong endorsement, but not at the cost of
making on-the-wire data meaningfully less secure.

At a minimum: could we agree that if a service/site is sensitive to privacy
- it's reasonable for them to prefer AES-CBC; should they be penalized in
SSL health analysis tools/reports for that configuration? it's not as
flexible or useful as the padding in TLS1.3, but it's what we have.

-- 
Colm