Re: Handling NULL key exchange for NULL_ ciphersuite

I'm not necessarily arguing against making NWNN illegal. But before we nail
the coffin closed. Just want to point out that negotiating to NWNN is safe
if NWNN is the only ciphersuite in the list! Ciphersuite rollback is not a
thread (as far as I can tell) in this circumstance. The upside is it would
be possible for an application to use NWNN over a port that was known to
speak TLS. Granted negotiating to NWNN might limit the range of objects
accessible to the caller but that is an access policy decision. TLS does
not specify an access model (policy) beyond setting up a channel.

Given that the issues related to port assignments are far from solved.
Wouldn't it be wise to allow the most flexibility in the protocol without
compromising security? I think NWNN all by itself should be considered. The
spec could be explicit about causing fatal alerts if NWNN were included
with other ciphersuites. 

Furthermore, a null session already in progress could negotiate up to a
more secure channel without an adverse impact on the security of the new
session. This seems like a great way for applications to implement stronger
security options within their protocol without breaking the connection?

Best Regards,
Ned Smith

At 02:13 AM 2/9/97 -0500, Win Treese wrote:
>To close out this issue, I propose that the TLS spec forbid
>negotiating to NULL_WITH_NULL_NULL. I understand
>the argument for testing, but I suspect the risks of this in
>practical deployment make it dangerous.
>Win Treese

Received on Monday, 10 February 1997 17:27:33 UTC