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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
