< draft-ietf-tls-session-hash-03.txt		draft-ietf-tls-session-hash-04.txt >
	Network Working Group K. Bhargavan		Network Working Group K. Bhargavan
	Internet-Draft A. Delignat-Lavaud		Internet-Draft A. Delignat-Lavaud
	Expires: May 16, 2015 A. Pironti		Expires: September 10, 2015 A. Pironti
	Inria Paris-Rocquencourt		Inria Paris-Rocquencourt
	A. Langley		A. Langley
	Google Inc.		Google Inc.
	M. Ray		M. Ray
	Microsoft Corp.		Microsoft Corp.
	November 12, 2014		March 9, 2015
	Transport Layer Security (TLS) Session Hash and		Transport Layer Security (TLS) Session Hash and
	Extended Master Secret Extension		Extended Master Secret Extension
	draft-ietf-tls-session-hash-03		draft-ietf-tls-session-hash-04
	Abstract		Abstract
	The Transport Layer Security (TLS) master secret is not		The Transport Layer Security (TLS) master secret is not
	cryptographically bound to important session parameters.		cryptographically bound to important session parameters such as the
	Consequently, it is possible for an active attacker to set up two		server certificate. Consequently, it is possible for an active
	sessions, one with a client and another with a server, such that the		attacker to set up two sessions, one with a client and another with a
	master secrets on the two sessions are the same. Thereafter, any		server, such that the master secrets on the two sessions are the
	mechanism that relies on the master secret for authentication,		same. Thereafter, any mechanism that relies on the master secret for
	including session resumption, becomes vulnerable to a man-in-the-		authentication, including session resumption, becomes vulnerable to a
	middle attack, where the attacker can simply forward messages back		man-in-the-middle attack, where the attacker can simply forward
	and forth between the client and server. This specification defines		messages back and forth between the client and server. This
	a TLS extension that contextually binds the master secret to a log of		specification defines a TLS extension that contextually binds the
	the full handshake that computes it, thus preventing such attacks.		master secret to a log of the full handshake that computes it, thus
			preventing such attacks.
	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 May 16, 2015.		This Internet-Draft will expire on September 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
	3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 5		3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 5
	4. The Extended Master Secret . . . . . . . . . . . . . . . . . 5		4. The Extended Master Secret . . . . . . . . . . . . . . . . . 5
	5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 6		5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 6
	5.1. Extension Definition . . . . . . . . . . . . . . . . . . 6		5.1. Extension Definition . . . . . . . . . . . . . . . . . . 6
	5.2. Client and Server Behavior . . . . . . . . . . . . . . . 6		5.2. Client and Server Behavior: Full Handshake . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5.3. Client and Server Behavior: Abbreviated Handshake . . . . 7
	6.1. Triple Handshake Preconditions and Impact . . . . . . . . 6		5.4. Interoperability Considerations . . . . . . . . . . . . . 8
	6.2. Cryptographic Properties of the Hash Function . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6.3. Session Hash Handshake Coverage . . . . . . . . . . . . . 8		6.1. Triple Handshake Preconditions and Impact . . . . . . . . 9
	6.4. No SSL 3.0 Support . . . . . . . . . . . . . . . . . . . 9		6.2. Cryptographic Properties of the Hash Function . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6.3. Handshake Messages included in the Session Hash . . . . . 10
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		6.4. No SSL 3.0 Support . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
			9.2. Informative References . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	In TLS [RFC5246], every session has a "master_secret" computed as:		In TLS [RFC5246], every session has a "master_secret" computed as:
	master_secret = PRF(pre_master_secret, "master secret",		master_secret = PRF(pre_master_secret, "master secret",
	ClientHello.random + ServerHello.random)		ClientHello.random + ServerHello.random)
	[0..47];		[0..47];
	where the "pre_master_secret" is the result of some key exchange		where the "pre_master_secret" is the result of some key exchange
	protocol. For example, when the handshake uses an RSA ciphersuite,		protocol. For example, when the handshake uses an RSA ciphersuite,
	this value is generated uniformly at random by the client, whereas		this value is generated uniformly at random by the client, whereas
	for DHE ciphersuites, it is the result of a Diffie-Hellman key		for DHE ciphersuites, it is the result of a Diffie-Hellman key
	agreement.		agreement.
	As described in [TRIPLE-HS], in both the RSA and DHE key exchanges,		As described in [TRIPLE-HS], in both the RSA and DHE key exchanges,
	an active attacker can synchronize two TLS sessions so that they		an active attacker can synchronize two TLS sessions so that they
	share the same "master_secret". For an RSA key exchange where the		share the same "master_secret". For an RSA key exchange where the
	client is unauthenticated, this is achieved as follows. Suppose a		client is unauthenticated, this is achieved as follows. Suppose a
	client, C, connects to a malicious server, A. A then connects to a		client C connects to a server A. C does not realize that A is
	server, S, and completes both handshakes. For simplicity, assume		malicious and that A connects in the background to an honest server S
	that C and S only use RSA ciphersuites. (Note that C thinks it is		and completes both handshakes. For simplicity, assume that C and S
	connecting to A and is oblivious of S's involvement.)		only use RSA ciphersuites.
	1. C sends a "ClientHello" to A, and A forwards it to S.		1. C sends a "ClientHello" to A, and A forwards it to S.
	2. S sends a "ServerHello" to A, and A forwards it to C.		2. S sends a "ServerHello" to A, and A forwards it to C.
	3. S sends a "Certificate", containing its certificate chain, to A.		3. S sends a "Certificate", containing its certificate chain, to A.
	A replaces it with its own certificate chain and sends it to C.		A replaces it with its own certificate chain and sends it to C.
	4. S sends a "ServerHelloDone" to A, and A forwards it to C.		4. S sends a "ServerHelloDone" to A, and A forwards it to C.
	5. C sends a "ClientKeyExchange" to A, containing the		5. C sends a "ClientKeyExchange" to A, containing the
	"pre_master_secret", encrypted with A's public key. A decrypts		"pre_master_secret", encrypted with A's public key. A decrypts
	the "pre_master_secret", re-encrypts it with S's public key and		the "pre_master_secret", re-encrypts it with S's public key and
	sends it on to S.		sends it on to S.
	6. C sends a "Finished" to A. A computes a "Finished" for its		6. C sends a "Finished" to A. A computes a "Finished" for its
	connection with S, and sends it to S.		connection with S, and sends it to S.
	7. S sends a "Finished" to A. A computes a "Finished" for its		7. S sends a "Finished" to A. A computes a "Finished" for its
	connection with C, and sends it to C.		connection with C, and sends it to C.
	At this point, both connections (between C and A, and between A and		At this point, both connections (between C and A, and between A and
	S) have new sessions that share the same "pre_master_secret",		S) have new sessions that share the same "pre_master_secret",
	"ClientHello.random", "ServerHello.random", as well as other session		"ClientHello.random", "ServerHello.random", as well as other session
	parameters, including the session identifier and, optionally, the		parameters, including the session identifier and, optionally, the
	session ticket. Hence, the "master_secret" value will be equal for		session ticket. Hence, the "master_secret" value will be equal for
	the two sessions and it will be associated both at C and S with the		the two sessions and it will be associated both at C and S with the
	same session ID, even though the server identities on the two		same session ID, even though the server identities on the two
	connections are different. Moreover, the record keys on the two		connections are different. Recall that C only sees A's certificate
	connections will also be the same.		and is unaware of A's connection with S. Moreover, the record keys on
			the two connections will also be the same.
	Similar scenarios can be achieved when the handshake uses a DHE		The above scenario shows that TLS does not guarantee that the master
	ciphersuite, or an ECDHE ciphersuite with an arbitrary explicit		secrets and keys used on different connections will be different.
	curve. Even if the client or server does not prefer using RSA or		Even if client authentication is used, the scenario still works,
	DHE, the attacker can force them to use it by offering only RSA or		except that the two sessions now differ on both client and server
	DHE in its hello messages. Other key exchanges may also be		identities.
	vulnerable. If client authentication is used, the attack still
	works, except that the two sessions now differ on both client and		A similar scenario can be achieved when the handshake uses a DHE
	server identities.		ciphersuite. Note that even if the client or server does not prefer
			using RSA or DHE, the attacker can force them to use it by offering
			only RSA or DHE in its hello messages. Handshakes using ECDHE
			ciphersuites are also vulnerable if they allow arbitrary explicit
			curves or use curves with small subgroups. Against more powerful
			adversaries, other key exchanges, such as SRP and PSK, have also been
			shown to be vulnerable [VERIFIED-BINDING].
	Once A has synchronized the two connections, since the keys are the		Once A has synchronized the two connections, since the keys are the
	same on the two sides, it can step away and transparently forward		same on the two sides, it can step away and transparently forward
	messages between C and S, reading and modifying when it desires. In		messages between C and S, reading and modifying when it desires. In
	the key exchange literature, such occurrences are called unknown key-		the key exchange literature, such occurrences are called unknown key-
	share attacks, since C and S share a secret but they both think that		share attacks, since C and S share a secret but they both think that
	their secret is shared only with A. In themselves, these attacks do		their secret is shared only with A. In themselves, these attacks do
	not break integrity or confidentiality between honest parties, but		not break integrity or confidentiality between honest parties, but
	they offer a useful starting point from which to mount impersonation		they offer a useful starting point from which to mount impersonation
	attacks on C and S.		attacks on C and S.
	Suppose C tries to resume its session on a new connection with A. A		Suppose C tries to resume its session on a new connection with A. A
	can then resume its session with S on a new connection and forward		can then resume its session with S on a new connection and forward
	the abbreviated handshake messages unchanged between C and S. Since		the abbreviated handshake messages unchanged between C and S. Since
	the abbreviated handshake only relies on the master secret for		the abbreviated handshake only relies on the master secret for
	authentication, and does not mention client or server identities,		authentication, and does not mention client or server identities,
	both handshakes complete successfully, resulting in the same session		both handshakes complete successfully, resulting in the same session
	keys and the same handshake log. A still knows the connection keys		keys and the same handshake log. A still knows the connection keys
	and can send messages to both C and S.		and can send messages to both C and S.
	Critically, on the new connection, even the handshake log is the same		Critically, on the new connection, even the handshake log is the same
	on C and S, thus defeating any man-in-the-middle protection scheme		on C and S, thus defeating any man-in-the-middle protection scheme
	that relies on the uniqueness of finished messages, such as the		that relies on the uniqueness of finished messages, such as the
	secure renegotiation indication extension [RFC5746] or TLS channel		secure renegotiation indication extension [RFC5746] or TLS channel
	bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on		bindings [RFC5929]. [TRIPLE-HS] describes several exploits based on
	such session synchronization attacks. In particular, it describes a		such session synchronization attacks. In particular, it describes a
	man-in-the-middle attack that circumvents the protections of		man-in-the-middle attack that circumvents the protections of
	[RFC5746] to break client-authenticated TLS renegotiation after		[RFC5746] to break client-authenticated TLS renegotiation after
	session resumption. Similar attacks apply to application-level		session resumption. Similar attacks apply to application-level
	authentication mechanisms that rely on channel bindings [RFC5929] or		authentication mechanisms that rely on channel bindings [RFC5929] or
	on key material exported from TLS [RFC5705].		on key material exported from TLS [RFC5705].
	The underlying protocol issue is that since the master secret is not		The underlying protocol issue leading to these attacks is that the
	guaranteed to be unique across sessions, it cannot be used on its own		TLS master secret is not guaranteed to be unique across sessions,
	as an authentication credential. This specification introduces a TLS		since it is not context-bound to the full handshake that generated
	extension that computes the "master_secret" value from the log of the		it. If we fix this problem in the initial master secret computation,
	handshake that computes it, so that different handshakes will, by		all these attacks can be prevented. This specification introduces a
	construction, create different master secrets.		TLS extension that changes the way the "master_secret" value is
			computed in a full handshake by including the log of the handshake
			messages, so that different sessions will, by construction, have
			different master secrets.
	2. Requirements Notation		2. Requirements Notation
	This document uses the same notation and terminology used in the TLS		This document uses the same notation and terminology used in the TLS
	Protocol specification [RFC5246].		Protocol specification [RFC5246].
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 41 ¶
	For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9		For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9
	of [RFC5246] for the Finished message computation. For all previous		of [RFC5246] for the Finished message computation. For all previous
	versions of TLS, the "Hash" function computes the concatenation of		versions of TLS, the "Hash" function computes the concatenation of
	MD5 and SHA1.		MD5 and SHA1.
	There is no "session_hash" for resumed handshakes, as they do not		There is no "session_hash" for resumed handshakes, as they do not
	lead to the creation of a new session.		lead to the creation of a new session.
	4. The Extended Master Secret		4. The Extended Master Secret
	When the extended master secret extension is negotiated in a TLS		When the extended master secret extension is negotiated in a full
	session, the "master_secret" is computed as		handshake, the "master_secret" is computed as
	master_secret = PRF(pre_master_secret, "extended master secret",		master_secret = PRF(pre_master_secret, "extended master secret",
	session_hash)		session_hash)
	[0..47];		[0..47];
	The extended master secret computation differs from the [RFC5246] in		The extended master secret computation differs from the [RFC5246] in
	the following ways:		the following ways:
	o The "extended master secret" label is used instead of "master		o The "extended master secret" label is used instead of "master
	secret";		secret";
	o The "session_hash" is used instead of the "ClientHello.random" and		o The "session_hash" is used instead of the "ClientHello.random" and
	"ServerHello.random".		"ServerHello.random".
	The "session_hash" depends upon a handshake log that includes		The "session_hash" depends upon a handshake log that includes
	"ClientHello.random" and "ServerHello.random", in addition to		"ClientHello.random" and "ServerHello.random", in addition to
	ciphersuites, key exchange information and client and server		ciphersuites, key exchange information, and certificates (if any)
	certificates. Consequently, the extended master secret depends upon		from the client and server. Consequently, the extended master secret
	the choice of all these session parameters.		depends upon the choice of all these session parameters.
	This design reflects the recommendation that keys should be bound to		This design reflects the recommendation that keys should be bound to
	the security contexts that compute them [sp800-108]. The technique		the security contexts that compute them [sp800-108]. The technique
	of mixing a hash of the key exchange messages into master key		of mixing a hash of the key exchange messages into master key
	derivation is already used in other well-known protocols such as SSH		derivation is already used in other well-known protocols such as SSH
	[RFC4251].		[RFC4251].
	Clients and servers SHOULD NOT resume sessions that do not use the		Clients and servers SHOULD NOT accept handshakes that do not use the
	extended master secret, especially if they rely on features like		extended master secret, especially if they rely on features like
	compound authentication that fall into the vulnerable cases described		compound authentication that fall into the vulnerable cases described
	in Section 6.1.		in Section 6.1.
	5. Extension Negotiation		5. Extension Negotiation
	5.1. Extension Definition		5.1. Extension Definition
	This document defines a new TLS extension, "extended_master_secret"		This document defines a new TLS extension, "extended_master_secret"
	(with extension type 0x0017), which is used to signal both client and		(with extension type 0x0017), which is used to signal both client and
	server to use the extended master secret computation. The		server to use the extended master secret computation. The
	"extension_data" field of this extension is empty. Thus, the entire		"extension_data" field of this extension is empty. Thus, the entire
	encoding of the extension is 00 17 00 00.		encoding of the extension is 00 17 00 00.
	If client and server agree on this extension and a full handshake		If the client and server agree on this extension, and a full
	takes place, both client and server MUST use the extended master		handshake takes place, both client and server MUST use the extended
	secret derivation algorithm, as defined in Section 4.		master secret derivation algorithm, as defined in Section 4.
	If an abbreviated handshake takes place, the extension has no effect.		If an abbreviated handshake takes place, the new connection keys are
	The resumed session is protected by the extended master secret if the		derived as usual from the (extended) master secret of the original
	extension was negotiated in the full handshake that generated the		handshake that created the resumed session.
	session.
	5.2. Client and Server Behavior		5.2. Client and Server Behavior: Full Handshake
	In its ClientHello message, a client implementing this document MUST		In the following, we use "aborting the handshake" as shorthand for
	send the "extended_master_secret" extension.		terminating the handshake by sending a fatal "handshake_failure"
			alert.
			In all handshakes, a client implementing this document MUST send the
			"extended_master_secret" extension in its ClientHello.
	If a server implementing this document receives the		If a server implementing this document receives the
	"extended_master_secret" extension, it MUST include the		"extended_master_secret" extension, it MUST include the
	"extended_master_secret" extension in its ServerHello message.		"extended_master_secret" extension in its ServerHello message.
			If the server receives a ClientHello without the extension, it SHOULD
			abort the handshake. If it chooses to continue, then it MUST NOT
			include the extension in the ServerHello.
			If a client receives a ServerHello without the extension, it SHOULD
			abort the handshake.
			In a full handshake, if both the ClientHello and ServerHello contain
			the extension, the new session uses the extended master secret
			computation.
			If the client or server choose to continue a full handshake without
			the extension, they use the legacy master secret derivation for the
			new session. In this case, the considerations in Section 5.4 apply.
			5.3. Client and Server Behavior: Abbreviated Handshake
			The client SHOULD NOT offer an abbreviated handshake to resume a
			session that does not use an extended master secret. The client MUST
			send the "extended_master_secret" extension in its ClientHello.
			If a server receives a ClientHello for an abbreviated handshake
			offering to resume a previous session, it behaves as follows.
			o If the original session did not use an extended master secret but
			the new ClientHello does contain the "extended_master_secret"
			extension, the server MUST abort the handshake.
			o If the new ClientHello does not contain the
			"extended_master_secret" extension, the server SHOULD fall back to
			a full handshake by sending a ServerHello that rejects the offered
			session but continues with a full handshake. If it continues with
			an abbreviated handshake the considerations in Section 5.4 apply.
			o If the ClientHello contains the extension and the server chooses
			to accept the abbreviated handshake, then the server MUST include
			the "extended_master_secret" extension in its ServerHello message.
			If a client receives a ServerHello that accepts an abbreviated
			handshake, it behaves as follows.
			o If the original session did not use an extended master secret but
			the new ServerHello does contain the "extended_master_secret"
			extension, the client MUST abort the handshake.
			o If the new ServerHello does not contain the
			"extended_master_secret" extension, the client SHOULD abort the
			handshake. If it continues with an abbreviated handshake the
			considerations in Section 5.4 apply.
			If the client and server continue the abbreviated handshake, they
			derive the connection keys for the new session as usual from the
			master secret of the original connection.
			5.4. Interoperability Considerations
			To allow interoperability with legacy clients and servers, a TLS peer
			may decide to accept handshakes that use the legacy master secret
			computation. If so, they need to differentiate between sessions that
			use legacy and extended master secrets by adding a flag to the
			session state.
			If a client or server chooses to continue with a full handshake
			without the extended master secret extension, the new session is
			vulnerable to the man-in-the-middle key synchronization attack
			described in Section 1. Hence, the client or server MUST NOT export
			any key material based on the new master secret for any subsequent
			application-level authentication. In particular, it MUST disable
			[RFC5705] and any EAP protocol relying on compound authentication
			[COMPOUND-AUTH].
			If a client or server chooses to continue an abbreviated handshake to
			resume a session that does not use the extended master secret, then
			the current connection is vulnerable to a man-in-the-middle handshake
			log synchronization attack as described in Section 1. Hence, the
			client or server MUST NOT use the current handshake's "verify_data"
			for application-level authentication. In particular, the client
			should disable renegotiation and any use of the "tls-unique" channel
			binding [RFC5929] on the current connection.
			If the original session uses an extended master secret, but the
			ClientHello or ServerHello in the abbreviated handshake does not
			include the extension, it MAY be safe to continue the abbreviated
			handshake since it is protected from the man-in-the-middle attack by
			the extended master secret. This scenario may occur, for example,
			when a server that implements this extension establishes a session,
			but the session is subsequently resumed at a different server that
			does not support the extension.
	6. Security Considerations		6. Security Considerations
	6.1. Triple Handshake Preconditions and Impact		6.1. Triple Handshake Preconditions and Impact
	One way to mount a triple handshake attack has been described in		One way to mount a triple handshake attack has been described in
	Section 1, along with a mention of the security mechanisms that break		Section 1, along with a mention of the security mechanisms that break
	due to the attack; more in-depth discussion and diagrams can be found		due to the attack; more in-depth discussion and diagrams can be found
	in [TRIPLE-HS]. Here, some further discussion is presented about		in [TRIPLE-HS]. Here, some further discussion is presented about
	attack preconditions and impact.		attack preconditions and impact.
	To mount a triple handshake attack, it must be possible to force the		To mount a triple handshake attack, it must be possible to force the
	same master secret on two different sessions. For this to happen,		same master secret on two different sessions. For this to happen,
	two preconditions must be met:		two preconditions must be met:
	o The client, C, must be willing to connect to a malicious server,		o The client, C, must be willing to connect to a malicious server,
	A. In certain contexts, like the web, this can be easily		A. In certain contexts, like the web, this can be easily achieved,
	achieved, since a browser can be instructed to load content from		since a browser can be instructed to load content from an
	an untrusted origin.		untrusted origin.
	o The pre-master secret must be synchronized on the two sessions.		o The pre-master secret must be synchronized on the two sessions.
	This is particularly easy to achieve with the RSA key exchange,		This is particularly easy to achieve with the RSA and DHE key
	but arbitrary DH groups or ECDH curves can be exploited to this		exchanges, but under some conditions, ECDHE, SRP, and PSK key
	effect as well.		exchanges can be exploited to this effect as well.
	Once the master secret is synchronized on two sessions, any security		Once the master secret is synchronized on two sessions, any security
	property that relies on the uniqueness of the master secret is		property that relies on the uniqueness of the master secret is
	compromised. For example, a TLS exporter [RFC5705] no longer		compromised. For example, a TLS exporter [RFC5705] no longer
	provides a unique key bound to the current session.		provides a unique key bound to the current session.
	TLS session resumption also relies on the uniqueness of the master		TLS session resumption also relies on the uniqueness of the master
	secret to authenticate the resuming peers. Hence, if a synchronized		secret to authenticate the resuming peers. Hence, if a synchronized
	session is resumed, the peers cannot be sure about each other		session is resumed, the peers cannot be sure about each other
	identity, and the attacker knows the connection keys. Clearly, a		identity, and the attacker knows the connection keys. Clearly, a
	skipping to change at page 8, line 8 ¶		skipping to change at page 10, line 18 ¶
	vulnerable to the attack.		vulnerable to the attack.
	The extended master secret extension thwarts triple handshake attacks		The extended master secret extension thwarts triple handshake attacks
	at their first stage, by ensuring that different sessions necessarily		at their first stage, by ensuring that different sessions necessarily
	end up with different master secret values. Hence, all security		end up with different master secret values. Hence, all security
	properties relying on the uniqueness of the master secret are now		properties relying on the uniqueness of the master secret are now
	expected to hold. In particular, if a TLS session is protected by		expected to hold. In particular, if a TLS session is protected by
	the extended master secret extension, it is safe to resume it, to use		the extended master secret extension, it is safe to resume it, to use
	its channel bindings, and to allow for certificate changes across		its channel bindings, and to allow for certificate changes across
	renegotiation, meaning that all certificates are controlled by the		renegotiation, meaning that all certificates are controlled by the
	same peer.		same peer. A symbolic cryptographic protocol analysis justifying the
			extended master secret extension appears in [VERIFIED-BINDING].
	6.2. Cryptographic Properties of the Hash Function		6.2. Cryptographic Properties of the Hash Function
	The session hashes of two different sessions need to be distinct,		The session hashes of two different sessions need to be distinct,
	hence the "Hash" function used to compute the "session_hash" needs to		hence the "Hash" function used to compute the "session_hash" needs to
	be collision resistant. As such, hash functions such as MD5 or SHA1		be collision resistant. As such, hash functions such as MD5 or SHA1
	are NOT RECOMMENDED.		are NOT RECOMMENDED.
	We observe that the "Hash" function used in the Finished message		We observe that the "Hash" function used in the Finished message
	computation already needs to be collision resistant, for the		computation already needs to be collision resistant, for the
	renegotiation indication extension [RFC5746] to work: a collision on		renegotiation indication extension [RFC5746] to work: a collision on
	the verify_data (and hence on the hash function computing the		the verify_data (and hence on the hash function computing the
	handshake messages hash) defeats the renegotiation indication		handshake messages hash) defeats the renegotiation indication
	countermeasure.		countermeasure.
	As a matter of fact, all current ciphersuites defined for TLS 1.2 use		The hash function used to compute the session hash depends on the TLS
	SHA256 or better. For earlier versions of the protocol, only MD5 and		protocol version. All current ciphersuites defined for TLS 1.2 use
	SHA1 can be assumed to be supported, and this document does not		SHA256 or better, and so does the session hash. For earlier versions
	require legacy implementations to add support for new hash functions.		of the protocol, only MD5 and SHA1 can be assumed to be supported,
			and this document does not require legacy implementations to add
			support for new hash functions. In these versions, the session hash
			uses the concatenation of MD5 and SHA1, as in the Finished message.
	6.3. Session Hash Handshake Coverage		6.3. Handshake Messages included in the Session Hash
	The "session_hash" is designed to encompass all relevant session		The "session_hash" is intended to encompass all relevant session
	information, including ciphersuite negotiation, key exchange messages		information, including ciphersuite negotiation, key exchange messages
	and client and server identities.		and client and server identities. The session hash needs to be
			available to compute the extended master secret before the Finished
			messages.
	This document sets the "session_hash" to cover all handshake messages		This document sets the "session_hash" to cover all handshake messages
	up to and including the ClientKeyExchange. In this way, on one hand,		up to and including the ClientKeyExchange. For existing TLS
	all the relevant session information is included; on the other hand,		ciphersuites, these messages include all the significant contents of
	the master secret can be computed right after the ClientKeyExchange		the new session---CertificateVerify does not change the session
	message, allowing implementations to shred the pre-master secret from		content. At the same time, this allows the extended master secret to
	memory as soon as possible.		be computed immediately after the pre-master secret, so that
			implementations can shred the temporary pre-master secret from memory
			as early as possible.
	It is crucial that any message sent after the ClientKeyExchange does		It is possible that new ciphersuites or TLS extensions may include
	not alter the session information. This is the case for the Finished		additional messages between ClientKeyExchange and Finished that add
	messages, as well as for the client CertificateVerify in client-		important session context. In such cases, some of the security
	authenticated sessions. This also applies to session ticket messages		guarantees of this specification may no longer apply, and new man-in-
	[RFC5077]. Any protocol extension that adds protocol messages after		the-middle attacks may be possible. For example, if the client and
	the Client Key Exchange MUST either ensure that such messages do not		server support the session ticket extension [RFC5077], the session
	alter the session information, or it MUST analyze the impact of the		hash does not cover the new session ticket sent by the server/ Hence,
	protocol changes with respect to the handshake coverage of the		a man-in-the-middle may be able to cause a client to store a session
	session hash.		ticket that was not meant for the current session. Attacks based on
			this vector are not yet known, but applications that store additional
			information in session tickets beyond those covered in the session
			hash require careful analysis.
	6.4. No SSL 3.0 Support		6.4. No SSL 3.0 Support
	SSL 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is		SSL 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is
	equally vulnerable to the triple handshake attacks.		equally vulnerable to the triple handshake attacks, alongside other
			vulnerabilities stemming from its use of obsolete cryptographic
			constructions that are now considered weak.
	The use of extensions precludes use of the extended master secret		The countermeasure described in this document relies on a TLS
	with SSL 3.0. Yet, this protocol uses encryption schemes and		extension and hence cannot be used with SSL 3.0. Clients and servers
	algorithms that are now considered weak. Furthermore, it seems		implementing this document SHOULD refuse SSL 3.0 handshakes. If they
	likely that any system that did not upgrate from SSL 3.0 to any later		choose to support SSL 3.0, the resulting sessions MUST use the legacy
	version of TLS will be exposed to several other vulnerabilties		master secret computation, and the interoperability considerations of
	anyway. As a consequence, this document does not provide workarounds		Section 5.4 apply.
	to accommodate SSL 3.0.
	7. IANA Considerations		7. IANA Considerations
	IANA has added the extension code point 23 (0x0017), which has been		IANA has added the extension code point 23 (0x0017), which has been
	used for prototype implementations, for the "extended_master_secret"		used by prototype implementations, for the "extended_master_secret"
	extension to the TLS ExtensionType values registry as specified in		extension to the TLS ExtensionType values registry as specified in
	TLS [RFC5246].		TLS [RFC5246].
	8. Acknowledgments		8. Acknowledgments
	The triple handshake attacks were originally discovered by Antoine		The triple handshake attacks were originally discovered by Antoine
	Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were		Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti, and were
	further developed by the miTLS team: Cedric Fournet, Pierre-Yves		further developed by the miTLS team: Cedric Fournet, Pierre-Yves
	Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the		Strub, Markulf Kohlweiss, Santiago Zanella-Beguelin. Many of the
	ideas in this draft emerged from discussions with Martin Abadi, Ben		ideas in this draft emerged from discussions with Martin Abadi, Ben
	skipping to change at page 10, line 23 ¶		skipping to change at page 12, line 46 ¶
	Server-Side State", RFC 5077, January 2008.		Server-Side State", RFC 5077, January 2008.
	[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.
	[TRIPLE-HS]		[TRIPLE-HS]
	Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,		Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
	A., and P. Strub, "Triple Handshakes and Cookie Cutters:		A., and P. Strub, "Triple Handshakes and Cookie Cutters:
	Breaking and Fixing Authentication over TLS", IEEE		Breaking and Fixing Authentication over TLS", IEEE
	Symposium on Security and Privacy, pages 98-113 , 2014.		Symposium on Security and Privacy (Oakland'14) , 2014.
			[VERIFIED-BINDING]
			Bhargavan, K., Delignat-Lavaud, A., and A. Pironti,
			"Verified Contributive Channel Bindings for Compound
			Authentication", Network and Distributed System Security
			Symposium (NDSS'14) , 2015.
	[sp800-108]		[sp800-108]
	Chen, L., "NIST Special Publication 800-108:		Chen, L., "NIST Special Publication 800-108:
	Recommendation for Key Derivation Using Pseudorandom		Recommendation for Key Derivation Using Pseudorandom
	Functions", Unpublished draft , 2009.		Functions", 2009.
			[COMPOUND-AUTH]
			Asokan, N., Valtteri, N., and K. Nyberg, "Man-in-the-
			middle in tunnelled authentication protocols", 2005.
	[Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009.		[Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009.
	Authors' Addresses		Authors' Addresses
	Karthikeyan Bhargavan		Karthikeyan Bhargavan
	Inria Paris-Rocquencourt		Inria Paris-Rocquencourt
	23, Avenue d'Italie		23, Avenue d'Italie
	Paris 75214 CEDEX 13		Paris 75214 CEDEX 13
	France		France
End of changes. 38 change blocks.
	107 lines changed or deleted		234 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/