- From: David P. Kemp <dpkemp@missi.ncsc.mil>
- Date: Tue, 28 Jan 1997 08:43:47 -0500
- To: ssl-talk@netscape.com
- Cc: ietf-tls@www10.w3.org
> > Anyone else want to see non-encrypted flavors get defined, like > a SSL_DHE_DSS_WITH_NULL_SHA flavor ?? Purely for parity with the > flavors relying on RSA certs for key exchange? Absolutely. For many of the applications I'm concerned with, authentication and integrity protection are far more important than confidentiality. It's true that "mix and match" CipherSuites are cause for concern and need to be carefully analyzed. And, as Wagner&Schneier points out, SSLRef 3.0b1 (a beta version) failed to include a check for the change cipher suite message, which could cause a problem with authentication-only CipherSuites but not with encrypted CipherSuites. This was an implementation error, not a protocol specification error, but I agree with W&S that the protocol specification should be changed to be more resistant to implementation errors. In any case, that particular problem affects RSA_WITH_NULL and DSS_WITH_NULL equally, so as long as RSA_WITH NULL exists, there shouldn't be a problem with the addition of both SSL_DHE_DSS_WITH_NULL_SHA and SSL_KEA_WITH_NULL_SHA to the TLS specifications.
Received on Tuesday, 28 January 1997 08:45:06 UTC