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

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

On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny <[e-mail]>
wrote:
>
> Well, you know already that we disagree on this :-)
>
> For everyone else's benefit, let me say the following:
>
> - Attacks only ever get better.
>

This applies to the passive size side-channel ones too though; and we're
seeing credible evidence that they're already happening today. I think
anything we can do here to raise costs for the attackers is worthwhile.


>
> - 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).
>

That's true, but I don't think it's all that relevant to the security of
TLS as used. In general DTLS has been more vulnerable to all sorts of
active protocol level attacks because of the weaker guarantees it can
provide.

- 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.
>

Well as the blog also explains, at no time was s2n succeptible to a Lucky13
vulnerability. In fact; as-it-was s2n did considerably better than
alternatives widely used in production. And that's my point here; we may be
over-indexing on the issue itself. Programmers certainly get things wrong -
though in this case the decision to use the hmac() construction as it is
specified (so that it can be formally verified against the specification)
was intentional.

But I take the point that AEAD modes are harder for programmers to screw
up; and that does have value. But my experience is that folks are pretty
good about keeping software up-to-date with patches and so on, and less
good about keeping configuration settings and protocol choices safe. As we
broaden the use of AEAD, more traffic becomes more susceptible to the very
real-world attacks above, and it's a "stickier" problem that will stay in
place.

I feel strongly that going back to MtE would be a retrograde step.
>

I don't like MtE one bit, but I also don't like zero length hiding one bit.
So it's a complicated nuanced trade-off.

-- 
Colm