support for SSL 2.0 in StartTLS-capable apps?

[email protected] Fri, 16 May 1997 06:51:24 -0700
Newsgroups gmane.ietf.apps-tls
Message-ID <[email protected]>
We'd noted that Paul included support for SSL 2.0 in 
draft-hoffman-smtp-ssl-02.txt. We included support for it in our proposed mods 
to the LDAPv3 protocol (included below for context, and perhaps feedback).

Is support for SSL 2.0 a requirement in general for StartTLS schemes? What do 
you folks think?

It was pointed out to us that TLS 1.0 protocol-02.txt has negotiation already, 
as described in appendix E:

|  TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
|  is easy. TLS clients who wish to negotiate with SSL 3.0 servers
|  should send client hello messages using the SSL 3.0 record format
|  and client hello structure, sending {3, 1} for the version field to
|  note that they support TLS 1.0. If the server supports only SSL 3.0,
|  it will respond with an SSL 3.0 server hello; if it supports TLS,
|  with a TLS server hello. The negotiation then proceeds as
|  appropriate for the negotiated protocol.


So, since the TLS spec doesn't mention SSL 2.0 in the section above, and since 
there doesn's seem to be an RFC or ID for it, then a client wishing to be able 
to support it in a StartTLS operation would need some way to let the server 
know that is what it was going to do. Hence our having a "tlsVersion" 
component to the StartTLSRequest..

	StartTLSRequest	::= [APPLICATION 30] SEQUENCE {
		tlsVersion		LDAPString }

But, if we dropped support for SSL 2.0, and only (implicityl) supported SSL 
3.0 and TLS 1.0 (by referencing the TLS spec), then we could conceivably 
reduce our StartTLS request to only..

	StartTLSRequest	::= [APPLICATION 30]

Feedback?

thanks,

Jeff Hodges
RL "Bob" Morgan
Stanford

ps: our proposed mods to LDAPv3 to support TLS on the standard port and to the 
URL format to support security policy expression is being discussed on the 
[email protected] list.