Re: Failed TLS negotiation

> On 23-Sep-98 at 15:02, John Gardiner Myers ([email protected]) wrote:
> > 
> > 
> > Chris Newman wrote:
> > > (A) close the connection if there's a TLS protocol error.
> > 
> > I believe this is your only choice, given the explicit directive in the
> > TLS specification.  Section 7.2.2 of draft-ietf-tls-protocol-05.txt
> > states "Upon transmission or receipt of an fatal alert message, both
> > parties immediately close the connection."
> > 
> > If you are willing to use a TCP connection in clear text, open a new
> > connection.
> 
> This was my understanding as well....but when I asked this question a couple of
> IETFs ago, I was told that this wasn't the correct interpretation of the spec:
> that the "connection" referred only to the TLS portion. Anybody have
> same/different memory of this?
> 
> /msb
> 
> > 
> 

I think there are three possible outcomes of a TLS negotiation:

(1) TLS protocol successful and the application verifies and accepts
    the certificate.

    Clearly in this case we can go on to transfer application data.

(2) TLS protocol successful but the application fails to verify the
    certificate and rejects the session.

    In this case, while the use of TLS has been rejected the protocol
    has still completed succesfully so it would be safe to go on to 
    transfer application data and perhaps attempt
    authentication/privacy in some other manner.

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



    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]