Re: Handling NULL key exchange for NULL_ ciphersuite

> Help me understand at what point the cipher suite rollbak attack can be
> waged (and if we care given that we are trying to use NWNN). We know the
> initial handshaking (implicitly using NWNN ciphersuite) is vulnerable to
> the attacks during handshaking until the finished message is sent which
> contains a mac on the entire handshake protocol. We can detect mischief by
> checking the MAC. The MAC is only as strong as the *new* ciphersuite
> dictates. If the new ciphersuite is NWNN (assuming we could negotiate to
> this ciphersuite) then we have not lost anything yet (nothing to loose).
> 
> At what point do any of the attacks in Wagner/Schneier translate to loss of
> security? Is it when an existing session re-hanshakes to a higher level of
> security? (Wagner/Schneier explicitly did not analyse this scenario for the
> ciphersuite rollback attack.) 

I think this question too can be answered by thinking in terms of
security policy.

The initial handshake, as you point out, starts out in NWNN.  But no
user data flows through the SSL connection until the first handshake is
complete.  If your policy is that NWNN is an acceptable ciphersuite,
then you will have a blue bar on your screen but no more protection
than with a non-TLS connection.  But hey, if that's your policy, who
can argue with it.

It doesn't really matter whether you negotiate down from a good
ciphersuite to NWNN, or pick NWNN as your initial ciphersuite after the
first handshake - the end result is a TLS connection that gives user
data no protection.

I'd also assume that changing your security policy (by clicking on the
options menu) would not force a new handshake for all existing
connections, but would only affect new connections established after
the policy change.  If the implementation does force a handshake for
existing connections, then the protocol certainly should switch to a new
ciphersuite from NWNN just as reliably in the middle of a connection as
it would have at the beginning.

Received on Wednesday, 5 February 1997 16:49:18 UTC