On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny <kenny.pater...@rhul.ac.uk> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
