Hi folks, Tuesday (14 January 2003)
At today's PSI Telecon, we agreed that a conforming PSI Client, Print
Service, or Target Device that claims to support secure operation MUST
support either: (a) Netscape SSL 3.0; or (b) IETF TLS 1.0 (version
"3.1" over-the-wire).
I further propose that a conforming PSI Client, Print Service, or Target
Device that claims to support secure operation MUST NOT negotiate down
to Netscape SSL 2.0 (to avoid compromised session security).
Per my action item from today's PSI Telecon, below are some details from
the IETF TLS 1.0 spec (RFC 2246) about fallback to Netscape SSL 3.0.
Cheers,
- Ira McDonald
High North Inc
------------------------------------------------------------------------
References for SSL and TLS specs:
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
Corp., Feb 9, 1995.
[SSL3] Frier, Karlton, Kocher, "The SSL 3.0 Protocol", Netscape
Communications Corp., Nov 18, 1996.
[TLS10] Dierks, Allen, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
- version "3.1" over-the-wire
ftp://ftp.isi.edu/in-notes/rfc2246.txt
[TLS11] Dierks, Rescorla, "The TLS Protocol Version 1.1",
work-in-progress, October 2002.
- version "3.2" over-the-wire
ftp://ftp.ietf.org/internet-drafts/
draft-ietf-tls-rfc2246-bis-02.txt
------------------------------------------------------------------------
Excerpt from "The TLS Protocol Version 1.0" (RFC 2246, January 1999):
E. Backward Compatibility With SSL
For historical reasons and in order to avoid a profligate consumption
of reserved port numbers, application protocols which are secured by
TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
connection port: for example, the https protocol (HTTP secured by SSL
or TLS) uses port 443 regardless of which security protocol it is
using. Thus, some mechanism must be determined to distinguish and
negotiate among the various protocols.
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.
Similarly, a TLS server which wishes to interoperate with SSL 3.0
clients should accept SSL 3.0 client hello messages and respond with
an SSL 3.0 server hello if an SSL 3.0 client hello is received which
has a version field of {3, 0}, denoting that this client does not
support TLS.
Whenever a client already knows the highest protocol known to a
server (for example, when resuming a session), it should initiate the
connection in that native protocol.
TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
Version 2.0 client hello messages [SSL2]. TLS servers should accept
either client hello format if they wish to support SSL 2.0 clients on
the same connection port. The only deviations from the Version 2.0
specification are the ability to specify a version with a value of
three and the support for more ciphering types in the CipherSpec.
Warning: The ability to send Version 2.0 client hello messages will be
phased out with all due haste. Implementors should make every
effort to move forward as quickly as possible. Version 3.0
provides better mechanisms for moving to newer versions.
The following cipher specifications are carryovers from SSL Version
2.0. These are assumed to use RSA for key exchange and
authentication.
V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
= { 0x04,0x00,0x80 };
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
Cipher specifications native to TLS can be included in Version 2.0
client hello messages using the syntax below. Any V2CipherSpec
element with its first byte equal to zero will be ignored by Version
2.0 servers. Clients sending any of the above V2CipherSpecs should
also include the TLS equivalent (see Appendix A.5):
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
This archive was generated by hypermail 2b29 : Tue Jan 14 2003 - 13:00:44 EST