Re: My two cents on TLS mandatory ciphers [Long]

[daw@xxxxxxxxxxxxxxx (David Wagner)]

In article <33C750A9.6EC0611A@xxxxxxxxxxxx>,
Tom Weinstein  <ietf-tls@xxxxxxxxxxxxx> wrote:
> David Wagner wrote:
> > I'm not aware of any full attack on non-encrypting ciphersuites at
> > present; but there have been at least two holes in recent versions
> > of SSL that would have been significantly exacerbated by support for
> > _NULL_ ciphersuites.  I'm worried that history may repeat itself --
> > that there may be other subtle weaknesses which would be greatly
> > exacerbated by support for auth-only ciphersuites.
> 
> What are the two holes you refer to?

Well, no one of them is compelling on its own, but the number of
them worries me.  Here are the ones I can think of right now:


Hole in SSL 2.0: ciphersuite rollback.  Because there was no auth-only
suite in SSL 2.0, the best an attacker could do was roll back to RC4-40,
and do a 2^40 keysearch (which is much less than 2^128, but still a
minor barrier).  If there had been support for _NULL_ ciphers, rollback
attacks would have been even more deadly.

Hole in SSL 3.0: Wiener's attack.  Some clients will send application
data before receiving a valid finished message.  This allows an active
attacker to rollback to an auth-only or 40-bit suite, not send the
server-finished message, and wait for the client to send application
data encrypted in that weakened ciphersuite.  If auth-only support
is turned off, a 2^40 (or more) keysearch is required; if _NULL_ suites
are supported, no keysearch is needed.

Hole in SSL 3.0: dropping the change cipher spec message.  When a
auth-only suite is negotiated, this active attack lets adversaries
defeat the authentication provisions, in some implementations.
If an encrypting ciphersuite is chosen, one must break the cipher
in real-time to break the authentication (still not good if RC4-40
is used, since authentication is supposed to take 2^128 work to
break, but a significant barrier).  Implementations which had turned
off support for auth-only ciphersuites would have been much less
vulnerable to this attack.

Finally, I note that Netscape's SSL 3.0 client implementation used
to allow a server to change the ciphersuite upon session resumption;
if the client supports _NULL_ suites, this allows a server to totally
turn off encryption.  Not a real security hole under most threat
models, but unexpected behavior.


Bottom line: if I were deploying a SSL/TLS implementation that needed
high-grade security (e.g. a 128-bit server for Internet banking applications),
I'd turn off support for auth-only, anonymous, and exportable ciphersuites.
(Even if I didn't know of any direct attacks, I'm worried enough by
the history to be especially cautious in this regard.)  That's why I
believe it would be a bad move to make any of those ciphersuites mandatory.