- From: Tom Weinstein <tomw@netscape.com>
- Date: Fri, 31 Jan 1997 09:19:18 -0800
- To: Tim Dierks <timd@consensus.com>
- CC: Ned Smith <nsmith@ibeam.jf.intel.com>, ietf-tls@www10.w3.org
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 Friday, 31 January 1997 12:13:23 UTC