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