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.) 

Tom when you say "nothing prevents an attacker from forcing you down to that
[NWNN] ciphersuite"; are you intimating that the ciphersuite list contains
non-NWNN ciphersuites?

Best Regards,
Ned
nsmith@ibeam.intel.com

At 09:19 AM 1/31/97 -0800, Tom Weinstein wrote:
>Tim Dierks wrote:
>> 
>>> I assume you mean TLS_NULL_WITH_NULL_NULL.  Although the spec does
>>> not explicitly forbid negotiating to this cipher suite, it should. 
>>> If an implementation allows negotiation to this cipher suite, it is
>>> open to a rollback attack.
>> 
>> It's not clear to me what you mean here, Tom. Since the original
>> negotiation of a connection occurs under NULL_WITH_NULL_NULL, I don't
>> understand how a later re-negotiation on the same communications
>> channel could be less secure than a new connection. Which rollback
>> attack do you mean? Cipher suites or SSL 2?
>
>The protocol explicitly forbids sending application data until after
>the first handshake has completed.
>
>If you renegotiate to a NULL_WITH_NULL_NULL cipher suite, nothing
>prevents an atacker from hijacking your connection at that point and
>substituting whatever data he wishes.  The Wagner-Schneier paper is
>very clear about this.  If you are interested in sending preencrypted
>data, you should negotiate down to something like RSA_WITH_NULL_SHA. 
>This still protects the integrity of your data while avoiding the
>overhead of encryption.
>
>Also, if you allow NULL_WITH_NULL_NULL to be negotiated at the initial
>handshake, nothing prevents an attacker from forcing you down to that
>ciphersuite.  One possible approach would be to provide some application
>layer mechanism for enabling and disabling the NULL_WITH_NULL_NULL
>cipher suite.  This requires smarts at a layer above TLS to turn it on
>and off, and TLS becomes vulnerable to bugs in that layer.  I'm not sure
>that's a problem we should be biting off.
>
>> Note: I do not recommend using NULL_WITH_NULL_NULL except unless you
>> know exactly why you want to and you know for a fact that you
>> understand your risk model. It provides no security over plain TCP/IP
>> and I wouldn't want anyone to think otherwise just because it's got
>> "TLS" in the name.
>
>Which is another good reason to forbid it.
>
>-- 
>You should only break rules of style if you can    | Tom Weinstein
>coherently explain what you gain by so doing.      | tomw@netscape.com
>
>

Received on Wednesday, 5 February 1997 15:21:59 UTC