Hi Colm, On 16/03/2016 14:52, "TLS on behalf of Colm MacCárthaigh" <tls-boun...@ietf.org on behalf of c...@allcosts.net> wrote: > >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/Upt >urn%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.
Well, you know already that we disagree on this :-) For everyone else's benefit, let me say the following: - Attacks only ever get better. - The Lucky 13 timing signal can be amplified for DTLS using packet trains (see this NDSS 2012 paper for the techniques: http://www.internetsociety.org/plain-text-recovery-attacks-against-datagram -tls). - As your blog nicely explains, AWS's s2n implementation chose to mitigate Lucky 13 using a bespoke solution. This code was found to be vulnerable to attack shortly after the code was released (https://eprint.iacr.org/2015/1129). The initial patch to the code was also insecure (https://eprint.iacr.org/2015/1241). Readers can draw their own conclusions from this. Mine is that even gifted programmers get TLS's MtE construction wrong. I feel strongly that going back to MtE would be a retrograde step. Much better would be implementing an optional padding feature for the AEAD modes. Something like this draft proposes: https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02 Cheers Kenny > > > >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
