Re: Failed TLS negotiation

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

Ok, I shouldn't haven't included the cipher suites in the above list
because the outcome there is deterministic.  That really falls into
case number 2 (TLS negotiation failure).  

But case number 3 is not about negotiation failures, it is about
protocol failures.  The state of the connection when the protocol
fails must be unknown.  If it were known then the protocol could
continue.  If the protocol failed it means that something unexpected
happened that the protocol and the protocol is unable to continue to
completion.  The end result is that you do not have a choice but to
close the connection and start over again and refuse to negotiate TLS
on the second try.

I really do not understand why this is considered to be so burdensome.




    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email protected]