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

["Paterson, Kenny" <[e-mail]>]

Hi Colm,

On 16/03/2016 14:52, "TLS on behalf of Colm MacCárthaigh"
<[e-mail] on behalf of [e-mail]> 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
>