< draft-turner-ssl-must-not-01.txt		draft-turner-ssl-must-not-02.txt >
	Network Working Group S. Turner		Network Working Group S. Turner
	Internet Draft IECA		Internet Draft IECA
	Updates: 5246 (once approved) Tim Polk		Updates: 5246 (once approved) Tim Polk
	Intended Status: BCP NIST		Intended Status: Standards Track NIST
	Expires: December 25, 2010 June 25, 2010		Expires: January 26, 2011 July 26, 2010
	Prohibiting SSL Version 3.0 and Earlier		Prohibiting SSL Version 2.0
	draft-turner-ssl-must-not-01.txt		draft-turner-ssl-must-not-02.txt
	Abstract		Abstract
	This document requires that when TLS clients and servers establish		This document requires that when TLS clients and servers establish
	connections that they never negotiate the use of Secure Sockets Layer		connections that they never negotiate the use of Secure Sockets Layer
	(SSL) version 3.0 or earlier. In addition, this document recommends		(SSL) version 2.0. This document updates the backward compatibility
	that TLS clients and servers not use TLS 1.0/SSL 3.1. This document		sections found in the Transport Security Layer (TLS) Protocol, RFC
	updates the backward compatibility sections found in the Transport		5246.
	Security Layer (TLS) Protocol, RFC 5246.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008.		available before November 10, 2008.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 42 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 25, 2010.		This Internet-Draft will expire on January 26, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	1. Introduction		1. Introduction
	Many protocols specified in the IETF rely on Transport Layer Security		Many protocols specified in the IETF rely on Transport Layer Security
	(TLS) [TLS1.0][TLS1.1][TLS1.2] for security services. This is a good		(TLS) [TLS] for security services. This is a good thing, but some
	thing, but some TLS clients and servers also support negotiating the		TLS clients and servers also support negotiating the use of SSL
	use of SSL version 2.0 [SSL2] and/or 3.0 [SSL3]; however, these		version 2.0 [SSL2]; however, this version does not provide the
	versions will not provide the expected level of security. Both SSL		expected level of security. SSL version 2.0 has known deficiencies.
	version 2.0 and 3.0 have known deficiencies. This document describes		This document describes those deficiencies, and it requires TLS
	those deficiencies, and it requires TLS clients and servers never		clients and servers never negotiate the use of SSL version 2.0.
	negotiate the use of SSL version 2.0 or 3.0.
	TLS has evolved from TLS 1.0 through 1.2. One change, which is
	addressed in Section 4, adopted by TLS 1.1 mitigates an attack
	against CBC modes used by TLS 1.0. As a result of this concern with
	TLS 1.0 this document recommends that TLS clients and servers never
	negotiate the use of TLS 1.0. Note that TLS 1.0 and SSL 3.1 are
	equivalent.
	This document updates the backward compatibility sections found in		This document updates the backward compatibility sections found in
	the Transport Security Layer (TLS) Protocol, RFC 5246.		the Transport Security Layer (TLS) Protocol [TLS] and earlier
			versions.
	1.1. Requirements Terminology		1.1. Requirements Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [WORDS].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	2. SSL2 Deficiencies		2. SSL 2.0
	SSL version 2.0 [SSL2] deficiencies include:		SSL version 2.0 [SSL2] deficiencies include:
	o Message authentication uses MD5 [MD5]. MD5 is universally accepted		o Message authentication uses MD5 [MD5]. Most security-aware users
	as a broken hash algorithm.		have already moved away from any of MD5
			[I-D.turner-md5-seccon-update].
	o Handshake messages are not protected. This permits a man-in-the-		o Handshake messages are not protected. This permits a man-in-the-
	middle to trick the client into picking a weaker cipher suite than		middle to trick the client into picking a weaker cipher suite than
	they would normally choose.		they would normally choose.
	o Message integrity and message encryption use the same key, which is		o Message integrity and message encryption use the same key, which
	a problem if the client and server negotiate a weak encryption		is a problem if the client and server negotiate a weak encryption
	algorithm.		algorithm.
	o Sessions can be easily terminated. A man-in-the-middle can easily		o Sessions can be easily terminated. A man-in-the-middle can easily
	insert a TCP FIN to close the session and the peer is unable to		insert a TCP FIN to close the session and the peer is unable to
	determine whether or not it was a legitimate end of the session.		determine whether or not it was a legitimate end of the session.
	3. SSL3 Deficiencies		3. Changes to TLS
	SSL version 3.0 [SSL3] has a primary key derivation function (KDF)
	deficiency. The SSL 3.0 KDF, which is used by all SSL 3.0 cipher
	suites, depends entirely upon the MD5 hash function [MD5] for half of
	the master key set up during the SSL key exchange. MD5 is not
	collision resistant and the pre-image resistance has been weakened by
	recent attacks.
	4. TLS 1.0 Deficiencies
	TLS 1.0 [TLS1.0] is an improvement over SSL 2.0 and 3.0; however, it
	too has deficiencies:
	o TLS 1.0 did not have explicit initialization vectors (IVs) in CBC
	mode. Explicit IVs were added to TLS 1.1 to prevent the attacks
	described in [CBC-Issues].
	o Some TLS 1.0 implementations incorrectly fail the handshake when
	there is data (e.g., extensions) following the ClientHello that
	they do not understand. This was a problem addressed in
	[RFC5746].
	5. Use TLS 1.0 and Later Versions
	Because of the deficiencies noted in the previous sections, TLS		Because of the deficiencies noted in the previous sections, TLS
	implementations MUST NOT support SSL 3.0 or earlier. Support for TLS		implementations MUST NOT support SSL 2.0. The specific changes to
	1.2 is RECOMMENDED. To ensure interoperability, TLS implementations		[TLS], including earlier versions, are as follows:
	MUST support TLS 1.0 and SHOULD support TLS 1.1 and 1.2. That is,
	TLS clients and servers MUST NOT request, offer, or use SSL 2.0 or
	SSL 3.0 and SHOULD offer TLS 1.2. The specific changes to [TLS1.2]
	are as follows:
	o TLS clients MUST NOT use SSL 2.0 ClientHello messages.
	o TLS servers MUST NOT accept SSL 2.0 ClientHello messages.
	o TLS clients MUST NOT use {3,0} in ClientHello.client_version.
	o TLS servers MUST NOT accept {3,0} in ClientHello.client_version; it		o TLS clients MUST NOT use SSL 2.0 ClientHello messages.
	MUST send a "protocol_version" alert message and close the
	connection.
	o TLS clients SHOULD offer {3,3} in ClientHello.client_version.		o TLS servers MUST NOT accept SSL 2.0 ClientHello messages.
	6. IANA Considerations		4. IANA Considerations
	None.		None.
	7. Security Considerations		5. Security Considerations
	The security considerations of [TLS1.0] [TLS1.1] [TLS1.2] apply; no
	new security considerations are introduced by this document.
	Since all recent TLS implementations support at least TLS 1.0/SSL		This entire document is about security considerations.
	3.1, the risk of denial of service from the lack of interoperability
	with earlier versions is considered minimal.
	8. Acknowledgements		6. Acknowledgements
	The idea for this document was inspired by discussions between Peter		The idea for this document was inspired by discussions between Peter
	Saint Andre, Simon Josefsson, and others on the XMPP mailing list.		Saint Andre, Simon Josefsson, and others on the XMPP mailing list.
			We would also like to thank Paul Hoffman, Yaron Sheffer, and Nikos
			Mavrogiannopoulos, Yngve Pettersen, Marsh Ray, and Martin Rex for
			reviews and comments.
	9. References		7. References
	9.1. Normative References
	[TLS1.0] Dierks, T. and C. Allen, "The Transport Layer		7.1. Normative References
	Security (TLS) Protocol Version 1.0", RFC 2246,
	January 1999.
	[TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Security (TLS) Protocol Version 1.1", RFC 4246,		Requirement Levels", BCP 14, RFC 2119, March 1997.
	April 2006.
	[TLS1.2] Dierks, T. and E. Rescorla, "The Transport Layer		[TLS] Dierks, T. and E. Rescorla, "The Transport Layer
	Security (TLS) Protocol Version 1.2", RFC 5246,		Security (TLS) Protocol Version 1.2", RFC 5246,
	August 2008.		August 2008.
	[WORDS] Bradner, S., "Key words for use in RFCs to Indicate		7.2. Informative References
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	9.2. Informative References
	[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC		[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
	1321, April 1992.		1321, April 1992.
	[RFC5746] Rescorla, E., Ray, M., Dispensa, S., Oskov, N.,
	"Transport Layer Security (TLS) Renegotiation
	Indication Extension", RFC 5746, February 2010.
	[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape		[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape
	Communications Corp., Feb 9, 1995.		Communications Corp., Feb 9, 1995.
	[SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0		[I-D.turner-md5-seccon-update] Turner, S., and L. Chen, "Updated
	Protocol", Netscape Communications Corp., Nov 18,		Security Considerations for the MD5 Message-Digest
	1996.		Algorithm", draft-turner-md5-seccon-update, work-in-
			progress.
	[CBC-Issues] Moeller, B., "Security of CBC Ciphersuites in
	SSL/TLS: Problems and Countermeasures",
	http://www.openssl.org/~bodo/tls-cbc.txt.
	Authors' Addresses		Authors' Addresses
	Sean Turner		Sean Turner
	IECA, Inc.		IECA, Inc.
	3057 Nutley Street, Suite 106		3057 Nutley Street, Suite 106
	Fairfax, VA 22031		Fairfax, VA 22031
	USA		USA
	EMail: turners@ieca.com		EMail: turners@ieca.com
	Tim Polk		Tim Polk
End of changes. 29 change blocks.
	108 lines changed or deleted		50 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/