Rather than trying to guess, I asked an expert who, in my
experience, always takes a "whole system" view of this sort of
issue. His response is forwarded with permission.
With all due respect to Steve, I don't think he's thought about this very hard
or considered the email situation specifically. For one thing, there are two
new attacks, not one.
Let's start by looking at the two new attacks. Lucky 13 is a repeated session
attack on CBC mode ciphers. A particular record in the data stream is modified
in different ways, causing the receiver to report an error, and how long it
takes to generate the report is measured. The number of sessions needed to
perform this attack is large (in expiriments it ranged from 2^15 to 2^22) and
LAN adjacency to the receiver was exploited. The number of sessions needed as
well as the amount of data that can be recovered vary enormously depending on
the TLS implementation and cipher suite used. But one of the ways to avoid
this attack is to use RC4, which because it doesn't require padding to a block
boundary is invulnerable to this type of attack. Note that any record in the
stream can be attacked; it doesn't have to be at the beginning.
The second (currently unnamed) attack is on RC4 specifically. This is a
repeated session eavesdropping attack and it only works on the first 256 bytes
of the stream. Some bytes can be deduced after 2^24 sessions and reliable
recovery is possible at around 2^30 session.
Given the overall characteristics of email sessions these are not remotely
feasible attacks. (There's some stuff in one of the papers about using malware
to cause lots of sessions to be generated; my position on that is given the
ability to infect the user's PC with malware there's so much more low-hanging
fruit I'm not worried about anyone using this attack on email.)
All that said, if you assume somone is going to attack email this way the thing
to go after rather obviously isn't message or envelope data - there's no
practical way to generate enough iterations of the same session/transaction for
that to work. User authentication credentials are another matter, however.
These occur consistently in the same place in email sessions.
The NOOP command/EHLO response business discussed could be used to improve
proection of these credentials in email sessions. But it's the length that
matters, not the content, because the goal is to make it impossible to
correlate the credentials found in multiple sessions.
However, there's a much simpler way to defeat these attacks: Use CRAM-MD5
or SCRAM-SHA1 under the SSL/TLS session instead of PLAIN. The changing
nonce will make it impossible to correlate credential information across
multiple sessions.
I will again repeat that these attacks are totally impractical in the email
space. But if you want to worry about them and for whatever reason you have to
fix things at the application layer, IMO the thing to do right now is to use an
RC4 cipher suite paired with CRAM-MD5 and/or SCRAM-SHA1 under your SSL/TLS
session for authentication.
And of course Steve is correct that a move away from RC4 is a good idea. (And
so is a move towards AES-GCM.) This has been true for a long time: It's
well known that there are structural weaknesses in RC4 (and CBC).
That said, I take issue with the apothegm that "attacks only get better, they
don't get worse". What seems to happen in practice is an attack is found, then
it is improved iteratively. Then after a while the improvements slow down and
finally stop. And then after a while a *new* attack, sometimes related,
sometimes not, is found and the process repeats. We've seen this pattern with
differential attacks, linear attacks, chosen prefix attacks, oracle padding
attacks, and so on.
What this says to me is that it doesn't make sense to expend a lot of effort on
defeating attacks that appear to be infeasible and which given due
consideration of the application space seem unlikely to become feasible.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp