Re: Failed TLS negotiation

Chris Newman <[email protected]> Mon, 28 Sep 1998 11:51:35 -0700 (PDT)
Newsgroups gmane.ietf.apps-tls
Message-ID <[email protected]>
On Fri, 25 Sep 1998, Jeffrey Altman wrote:
> (3) TLS protocol fails.  
> 
>     This can be caused by a configuration error (inability to access a
>     file, a verification server, ...); lack of a common set of
>     ciphers, MACs, ...; data corruption; ...
>
>     In this case it is not safe to transfer application data because 
>     there is no ability to guarrantee the state of the connection.

Actually, this sounds like two different cases: protocol errors and
negotiation failures.  In the case of a negotiation failure, there could
be a deterministic outcome, but I don't understand the nitty-gritty of the
TLS spec enough to speculate if it permits anything other than closing the
connection in such a case.  A protocol error would result from data
corruption or something else that would force a non-deterministic outcome. 

It's cumbersome to try TLS negotiation, fail, close and reopen the socket
without trying TLS negotation.  Much easier to try TLS negotation, fail
and continue.  The common case where that's desired is failed cipher suite
negotiation.  Given the installed base of RSA-patented (or trade secret) 
cipher suites and export crippled cipher-suites and the IETF requirement
for a full-strength patent-free mandatory-to-implement cipher suite, I
expect cipher suite negotiation failures to be common in the real world,
even if they can never happen between two correctly configured
fully-compliant implementations.

		- Chris