--On Thursday, March 21, 2013 00:47 -0700 "Carl S. Gutekunst"
<csg(_at_)alameth(_dot_)org> wrote:
This is a question for folks that actually know crypto, and
also know SMTP.
A common theme of many of the recent statistical attacks on
TLS (BEAST, Lucky 13, the ABPPS RC4 attack) has been knowing
that some early part of the plaintext was constant. Knowing
that some of the early bytes are limited to a range, or even
fully known, was even more helpful.
On every SMTP server in the world, the first 100 to 250 bytes
send by the server after TLS negotiation completes are both
constant and known: they're the EHLO response. So that got me
wondering if randomizing the EHLO response could be helpful in
mitigating statistical attacks.
...
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.
john
--On Thursday, March 21, 2013 09:26 -0400 Steven Bellovin
<smb(_at_)cs(_dot_)columbia(_dot_)edu> wrote:
The right answer is to move away from RC4. A crypto algorithm
that is vulnerable in a situation like that is unacceptably
weak. RC4 was important 15 years ago, when computers were
slower and the only real alternative was DES, which -- apart
from its weaknesses -- was very slow in software. Today, we
have fast computers and AES. (There's also a new stream
cipher being discussed in the CFRG, but it's too soon to adopt
it.) I suspect that virtually every TLS implementation in the
wild today supports AES; it's just a configuration change.
(Btw -- unless your enemy is the NSA or its non-US equivalents,
cryptanalysis is the least of your worries. Hacking in is so
much easier.)
3 days ago, David McGrew -- co-chair of CFRG -- agreed that
RC4 should be deprecated:
https://www.ietf.org/mail-archive/web/cfrg/current/msg03342.ht
ml This new result is not a surprise to anyone in the field;
it's been known to be dubious for a fair number of years.
Here's what I wrote last summer (or earlier) in the crypto
chapter of a book I'm writing:
Stream ciphers are harder to employ properly than are block
ciphers, but they do have their uses. RC45 is by far the
most popular choice, and it is extremely fast; that said, it
appears to have a number of cryptanalytic weaknesses [Golic,
1997; Knudsen et al., 1998. It's probably best to avoid new
uses unless you really need its blinding speed; instead, use
AES in counter mode.
Obviously, I need to strengthen that. Btw, note the dates on
the citations.
RC4 has enjoyed something of a comeback because of CBC-related
weaknesses in TLS. Again, the right choice is to fix TLS.
You may be interested in a 1997 paper of mine; it's also based
on known or guessable plaintext:
https://www.cs.columbia.edu/~smb/papers/probtxt.pdf . Note
the strongest recommendation: "The simplest defense, of
course, is to avoid use of weak ciphers. There is little
doubt that DES is inadequate against a serious opponent. That
security systems based on it should be vulnerable is not
surprising; what we have simply analyzed exactly how to attack
one instantiation."
Feel free to send this to the list, with my name on it. I
doubt you'd get different advice from anyone else in the
security area, with the possible exception of whether or not
that new stream cipher (Salsa20) is ready for prime time.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp