< draft-bmoeller-tls-downgrade-scsv-01.txt		draft-bmoeller-tls-downgrade-scsv-02.txt >
	Network Working Group B. Moeller		Network Working Group B. Moeller
	Internet-Draft A. Langley		Internet-Draft A. Langley
	Updates: 2246,4346,5246 Google		Updates: 2246,4346,5246 Google
	(if approved) November 28, 2013		(if approved) June 1, 2014
	Intended status: Standards Track		Intended status: Standards Track
	Expires: June 1, 2014		Expires: December 3, 2014
	TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol		TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol
	Downgrade Attacks		Downgrade Attacks
	draft-bmoeller-tls-downgrade-scsv-01		draft-bmoeller-tls-downgrade-scsv-02
	Abstract		Abstract
	This document defines a Signaling Cipher Suite Value (SCSV) that		This document defines a Signaling Cipher Suite Value (SCSV) that
	prevents protocol downgrade attacks on the Transport Layer Security		prevents protocol downgrade attacks on the Transport Layer Security
	(TLS) protocol.		(TLS) protocol. It updates RFC 2246, RFC 4346, and 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.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on June 1, 2014.		This Internet-Draft will expire on December 3, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol values . . . . . . . . . . . . . . . . . . . . . . . 4		2. Protocol values . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 5		3. Server behavior . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 6		4. Client behavior . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.2. Informal References . . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9		7.2. Informal References . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	To work around interoperability problems with legacy servers, many		To work around interoperability problems with legacy servers, many
	TLS client implementations do not rely on the TLS protocol version		TLS client implementations do not rely on the TLS protocol version
	negotiation mechanism alone, but will intentionally reconnect using a		negotiation mechanism alone, but will intentionally reconnect using a
	downgraded protocol if initial handshake attempts fail. Such clients		downgraded protocol if initial handshake attempts fail. Such clients
	may fall back to connections in which they announce a version as low		may fall back to connections in which they announce a version as low
	as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest		as TLS 1.0 (or even its predecessor, SSL 3.0) as the highest
	supported version.		supported version.
	While such protocol downgrades can be a useful last resort for		While such protocol downgrades can be a useful last resort for
	connections to actual legacy servers, there's a risk that active		connections to actual legacy servers, there's a risk that active
	attackers could exploit the downgrade strategy to weaken the		attackers could exploit the downgrade strategy to weaken the
	cryptographic security of connections. Also, handshake errors due to		cryptographic security of connections. Also, handshake errors due to
	network glitches could similary be misinterpreted as interaction with		network glitches could similarly be misinterpreted as interaction
	a legacy server and result in a protocol downgrade.		with a legacy server and result in a protocol downgrade.
	All unnecessary protocol downgrades are undesirable (e.g., from TLS		All unnecessary protocol downgrades are undesirable (e.g., from TLS
	1.2 to TLS 1.1 if both the client and the server actually do support		1.2 to TLS 1.1 if both the client and the server actually do support
	TLS 1.2); they can be particularly critical if they mean losing the		TLS 1.2); they can be particularly critical if they mean losing the
	TLS extension feature (when downgrading to SSL 3.0). This document		TLS extension feature (when downgrading to SSL 3.0). This document
	defines a Signaling Cipher Suite Value (SCSV) that can be employed to		defines a Signaling Cipher Suite Value (SCSV) that can be employed to
	prevent unintended protocol downgrades between clients and servers		prevent unintended protocol downgrades between clients and servers
	that comply to this document, by having the client indicate that the		that comply to this document, by having the client indicate that the
	current connection attempt is merely a fallback.		current connection attempt is merely a fallback.
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	relevant if such implementations also include support for predecessor		relevant if such implementations also include support for predecessor
	protocol SSL 3.0 [RFC6101].) It can be applied similarly to later		protocol SSL 3.0 [RFC6101].) It can be applied similarly to later
	protocol versions.		protocol versions.
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Protocol values		2. Protocol values
	[[ NOTE IN DRAFT: The following registry allocations require		This document defines a new TLS cipher suite value:
	Standards Action, i.e. will only be official with the IESG's
	Standards Track RFC approval. ]]
	This document allocates a new cipher suite value in the TLS Cipher
	Suite Registry [RFC5246]:
	TLS_FALLBACK_SCSV {0x56, 0x00}		TLS_FALLBACK_SCSV {0x56, 0x00}
	This is a signaling cipher suite value, i.e., it does not actually		This is a signaling cipher suite value (SCSV), i.e., it does not
	correspond to a suite of cryptosystems, and it can never be selected		actually correspond to a suite of cryptosystems, and it can never be
	by the server in the handshake; rather, its presence in the client		selected by the server in the handshake; rather, its presence in the
	hello message serves as a backwards-compatible signal from the client		client hello message serves as a backwards-compatible signal from the
	to the server.		client to the server.
	This document also allocates a new alert value in the TLS Alert		This document also allocates a new alert value in the TLS Alert
	Registry [RFC5246]:		Registry [RFC5246]:
	enum {		enum {
	/* ... */		/* ... */
	inappropriate_fallback(86),		inappropriate_fallback(86),
	/* ... */		/* ... */
	(255)		(255)
	} AlertDescription;		} AlertDescription;
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	3. Server behavior		3. Server behavior
	This section specifies server behavior when receiving the		This section specifies server behavior when receiving the
	TLS_FALLBACK_SCSV cipher suite from a client in		TLS_FALLBACK_SCSV cipher suite from a client in
	ClientHello.cipher_suites.		ClientHello.cipher_suites.
	o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the		o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
	highest protocol version supported by the server is higher than		highest protocol version supported by the server is higher than
	the version indicated in ClientHello.client_version, the server		the version indicated in ClientHello.client_version, the server
	MUST respond with a inappropriate_fallback alert.		MUST respond with an inappropriate_fallback alert.
	Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears		Otherwise (either TLS_FALLBACK_SCSV does not appear, or it appears
	and the client's protocol version is at least the highest protocol		and the client's protocol version is at least the highest protocol
	version supported by the server), the server proceeds with the		version supported by the server), the server proceeds with the
	handshake as usual.		handshake as usual.
	4. Client behavior		4. Client behavior
	The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients		The TLS_FALLBACK_SCSV cipher suite value is meant for use by clients
	that repeat a connection attempt with a downgraded protocol in order		that repeat a connection attempt with a downgraded protocol in order
	to avoid interoperability problems with legacy servers. This section		to avoid interoperability problems with legacy servers. This section
	specifies when to send it.		specifies when to send it.
	o If a client sends a ClientHello.client_version containing a lower		o If a client sends a ClientHello.client_version containing a lower
	value than the latest (highest-valued) version supported by the		value than the latest (highest-valued) version supported by the
	client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value		client, it SHOULD include the TLS_FALLBACK_SCSV cipher suite value
	in ClientHello.cipher_suites. This does not apply when the client		in ClientHello.cipher_suites. (Since the cipher suite list in the
	intends to perform an abbreviated handshake to resume a previously		ClientHello is ordered by preference, with the client's favorite
	negotiated session and sets ClientHello.client_version to the		choice first, signaling cipher suite values will generally appear
	protocol version negotiated for that session.		after all cipher suites that the client actually intends to
			negotiate.)
			However, as an exception to the above, when the client intends to
			perform an abbreviated handshake to resume a previously negotiated
			session and sets ClientHello.client_version to the protocol
			version negotiated for that session, the client MUST NOT include
			TLS_FALLBACK_SCSV in ClientHello.cipher_suites.
	Note that in the above, a protocol version is not considered		Note that in the above, a protocol version is not considered
	supported by the client if it has been disabled by any applicable		supported by the client if it has been disabled by any applicable
	system or user settings: it is about the highest protocol version		system or user settings: it is about the highest protocol version
	that the client would attempt using in a handshake, not about the		that the client would attempt using in a handshake, not about the
	highest protocol version implemented if its use is not actually		highest protocol version implemented if its use is not actually
	enabled. (For example, if the implementation supports TLS 1.2 but		enabled. (For example, if the implementation supports TLS 1.2 but
	the user has disabled this protocol version, a TLS 1.1 handshake is		the user has disabled this protocol version, a TLS 1.1 handshake is
	expected and does not warrant sending TLS_FALLBACK_SCSV.)		expected and does not warrant sending TLS_FALLBACK_SCSV.)
	skipping to change at page 7, line 17 ¶		skipping to change at page 7, line 17 ¶
	Section 4 does not require client implementations to send		Section 4 does not require client implementations to send
	TLS_FALLBACK_SCSV in any particular case, it merely recommends it;		TLS_FALLBACK_SCSV in any particular case, it merely recommends it;
	behavior can be adapted according to the client's security needs.		behavior can be adapted according to the client's security needs.
	For example, during the initial deployment of a new protocol version		For example, during the initial deployment of a new protocol version
	(when some interoperability problems may have to be expected),		(when some interoperability problems may have to be expected),
	smoothly falling back to the previous protocol version in case of		smoothly falling back to the previous protocol version in case of
	problems may be preferrable to potentially not being able to connect		problems may be preferrable to potentially not being able to connect
	at all: so TLS_FALLBACK_SCSV could be omitted for this particular		at all: so TLS_FALLBACK_SCSV could be omitted for this particular
	protocol downgrade step.		protocol downgrade step.
	However, it is particularly strongly recommended to send		However, it is strongly recommended to send TLS_FALLBACK_SCSV when
	TLS_FALLBACK_SCSV when downgrading to SSL 3.0 as the CBC cipher		downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have
	suites in SSL 3.0 have weaknesses that cannot be addressed by		weaknesses that cannot be addressed by implementation workarounds
	implementation workarounds like the remaining weaknesses in later		like the remaining weaknesses in later (TLS) protocol versions.
	(TLS) protocol versions.
	6. References		6. IANA Considerations
	6.1. Normative References		[[ NOTE IN DRAFT: The requested registry allocation requires
			Standards Action, i.e., will only be official with the IESG's
			Standards Track RFC approval. Since this document is currently an
			Internet-Draft, IANA so far has in fact not added the cipher suite
			number to the registry. ]]
			IANA has added TLS cipher suite number 0x56,0x00 with name
			TLS_FALLBACK_SCSV to the TLS Cipher Suite registry.
			7. References
			7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.		(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	6.2. Informal References		7.2. Informal References
	[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure		[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
	Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,		Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
	August 2011.		August 2011.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This specification was inspired by an earlier proposal by Eric		This specification was inspired by an earlier proposal by Eric
	Rescorla.		Rescorla.
	skipping to change at page 10, line 17 ¶		skipping to change at page 11, line 17 ¶
	Bodo Moeller		Bodo Moeller
	Google Switzerland GmbH		Google Switzerland GmbH
	Brandschenkestrasse 110		Brandschenkestrasse 110
	Zurich 8002		Zurich 8002
	Switzerland		Switzerland
	Email: bmoeller@acm.org		Email: bmoeller@acm.org
	Adam Langley		Adam Langley
	Google Inc.		Google Inc.
	76 9th Ave		345 Spear St
	New York, NY 10011		San Francisco, CA 94105
	USA		USA
	Email: agl@google.com		Email: agl@google.com
End of changes. 17 change blocks.
	39 lines changed or deleted		52 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/