[Top] [All Lists]

Re: [ietf-smtp] When using TLS, would randomizing the order of the EHLO response be helpful?

2013-03-21 10:29:01
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.
Obviously the degree of "randomizing" is limited; RFC 5321 requires the
first line to be the FQDN of the receiver, and every line will contain
"\r\n\220-". The most I can do is randomize whole lines. But I don't
have an intuitive feel for what might be effective in disrupting these
statistical code-breaking techniques; hence the question.

I fully understand that fixing the vulnerabilities is much more
important, but with RC4 in particular I'm wondering about hacks that
might keep it a little more secure, a little bit longer.

An even simpler thing to do, and which introduces far more variability to the
initial server response than reording is to return something like this:

S: 250-XRAND p9g8u340prt8u390pr83uyfo983yro937yr9o37yr397h
S: ...

Randomizing what the client initially sends is also pretty easy:

C: NOOP rp08tu098309r8u309r8uy390r8u309r8u39r8u3
S: ...
C: EHLO ...

As to whether or not this is actually useful, I'll try to have to say about
that in a bit. (I'm trying to come up speed on the RC4 attack; it's not easy
given the paper on it doesn't seem to be available yet. If someone know
otherwise I'd appreciate a pointer.)

ietf-smtp mailing list