Re: Failed TLS negotiation

This issue was taken up while working out LDAP use of TLS.  In the LDAP
case folks are interested in continuing the TCP connection even after use
of TLS is ended.  The case you mention, ending TLS due to negotiation
failure, is IMHO just one of those cases.  Tim Dierks suggested these
changes to section 7.2.1 of tls-protocol:

  Original text:

   Each party is required to send a close_notify alert before closing
   the write side of the connection. It is required that the other
   party respond with a close_notify alert of its own and close down
   the connection immediately, discarding any pending writes. It is not
   required for the initiator of the close to wait for the responding
   close_notify alert before closing the read side of the connection.

  Plus the following:

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport, the TLS implementation must
   recieve the responding close_notify alert before indicating to the
   application layer that the TLS connection has ended. If the
   application protocol will not transfer any additional data, but
   will only close the underlying transport connection, then the
   implementation may choose to close the transport without waiting for
   the responding close_notify.

to clarify the behavior.  Tim has said that this language should be
included in an -06 draft, which everyone fervently hopes will be the one
that goes to RFC.

Furthermore, my notes from the TLS WG meeting in Chicago show that Tim D
said that he was intending to add language to -06 saying something like
"changes in state of TLS never imply anything about the state of the
underlying transport", since obviously the current use of "connection" is
ambiguous.  (In fact I find the use of "connection" and "session"
throughout tls-protocol to be inconsistent and confusing, but if the
implementors like it, hey I won't complain.)

So, I'd say that Chris's choice C is acceptable from a protocol point of
view.

 - RL "Bob"

---

On Wed, 23 Sep 1998, Chris Newman wrote:

> When a TLS negotiation fails (as distinct from a TLS protocol error), is
> there a guarantee that all TLS packets are consumed, or is the socket in
> an indeterminate state?
> 
> I'm interested in the scenario where both client and server are set to the
> "use TLS if possible" mode (which I consider the correct default for
> clients and servers -- both should also have a setting to insist on TLS).
> In this scenario, when the TLS negotiation fails the most desirable option
> is to continue the TCP connection in clear text.
> 
> Along these lines, I'm trying to think of what to say (and what to
> implement) for the "STARTTLS" command in IMAP on a TLS negotiation
> failure.  I'd be inclined to say that the server should: 
> 
> (A) close the connection if there's a TLS protocol error.
> (B) Send a "* BYE TLS Required" and close the connection if there's a
>     negotiation failure and the server requires the use of TLS.
> (C) Continue the IMAP protocol if the server is willing to accept
>     connections without TLS.
> 
> Comments?
> 
> 		- Chris