< draft-ietf-tls-session-hash-02.txt		draft-ietf-tls-session-hash-03.txt >
	Network Working Group K. Bhargavan		Network Working Group K. Bhargavan
	Internet-Draft A. Delignat-Lavaud		Internet-Draft A. Delignat-Lavaud
	Expires: April 9, 2015 A. Pironti		Expires: May 16, 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.
	October 6, 2014		November 12, 2014
	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-02		draft-ietf-tls-session-hash-03
	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 such as the		cryptographically bound to important session parameters.
	client and server identities. Consequently, it is possible for an		Consequently, it is possible for an active attacker to set up two
	active attacker to set up two sessions, one with a client and another		sessions, one with a client and another with a server, such that the
	with a server, such that the master secrets on the two sessions are		master secrets on the two sessions are the same. Thereafter, any
	the same. Thereafter, any mechanism that relies on the master secret		mechanism that relies on the master secret for authentication,
	for authentication, including session resumption, becomes vulnerable		including session resumption, becomes vulnerable to a man-in-the-
	to a man-in-the-middle attack, where the attacker can simply forward		middle attack, where the attacker can simply forward messages back
	messages back and forth between the client and server. This		and forth between the client and server. This specification defines
	specification defines a TLS extension that contextually binds the		a TLS extension that contextually binds the master secret to a log of
	master secret to a log of the full handshake that computes it, thus		the full handshake that computes it, thus preventing such attacks.
	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 April 9, 2015.		This Internet-Draft will expire on May 16, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	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 . . . . . . . . . . . . . . . . . . . . 4
	3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 5		3. The TLS Session Hash . . . . . . . . . . . . . . . . . . . . 5
	4. The extended master secret . . . . . . . . . . . . . . . . . 5		4. The Extended Master Secret . . . . . . . . . . . . . . . . . 5
	4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Extension Negotiation . . . . . . . . . . . . . . . . . . . . 6
	4.2. SSL 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . 6		5.1. Extension Definition . . . . . . . . . . . . . . . . . . 6
	5. Extension negotiation . . . . . . . . . . . . . . . . . . . . 6		5.2. Client and Server Behavior . . . . . . . . . . . . . . . 6
	5.1. Extension definition . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5.2. Client and Server Behavior . . . . . . . . . . . . . . . 7		6.1. Triple Handshake Preconditions and Impact . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6.2. Cryptographic Properties of the Hash Function . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6.3. Session Hash Handshake Coverage . . . . . . . . . . . . . 8
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		6.4. No SSL 3.0 Support . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 9
			9.2. Informative References . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	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
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 11 ¶
	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].
	3. The TLS Session Hash		3. The TLS Session Hash
	When a full handshake takes place, we define		When a full TLS handshake takes place, we define
	session_hash = Hash(handshake_messages)		session_hash = Hash(handshake_messages)
	where "handshake_messages" refers to all handshake messages sent or		where "handshake_messages" refers to all handshake messages sent or
	received, starting at client hello up to and including the Client Key		received, starting at the ClientHello up to and including the
	Exchange message, including the type and length fields of the		ClientKeyExchange message, including the type and length fields of
	handshake messages. This is the concatenation of all the exchanged		the handshake messages. This is the concatenation of all the
	Handshake structures, as defined in Section 7.4 of [RFC5246].		exchanged Handshake structures, as defined in Section 7.4 of
			[RFC5246].
	The hash function "Hash" is defined by the ciphersuite in TLS 1.2.		For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9
	In all previous versions of TLS and in SSL 3.0, this function		of [RFC5246] for the Finished message computation. For all previous
	computes the concatenation of MD5 and SHA1.		versions of TLS, the "Hash" function computes the concatenation of
			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.
	Implementation note: As described in Section 4, the "session_hash" is		4. The Extended Master Secret
	used in the extended master secret computation. Hence, it must be
	possible to compute the session_hash before the master secret is
	computed. In SSL 3.0, the master secret is first needed in the
	Client's CertificateVerify message. Hence, it is widespread
	implementation practice to compute the master secret as soon as the
	"pre_master_secret" is available, typically immediately before or
	after sending the Client Key Exchange message. The definition of
	"session_hash" given in this document requires minimal patches to
	such implementations in order to implement the extended master secret
	extension. Our definition is also compatible with the common
	implementation practice of keeping running hashes of the handshake
	log.
	4. The extended master secret
	4.1. TLS
	When the extended master secret extension is negotiated in a TLS		When the extended master secret extension is negotiated in a TLS
	session, the "master_secret" is computed as		session, 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, client and server certificates. Consequently, the		ciphersuites, key exchange information and client and server
	extended master secret depends upon the choice of all these session		certificates. Consequently, the extended master secret depends upon
	parameters.		the choice of all these session parameters.
	Our proposed design reflects the recommendation that keys should be
	bound to the security contexts that compute them [sp800-108]. The
	technique of mixing a hash of the key exchange messages into master
	key derivation is already used in other well-known protocols such as
	SSH [RFC4251].
	4.2. SSL 3.0
	SSL 3.0 does not defne a PRF function, instead it defines a custom
	algorithm to compute the master secret. When the extended master
	secret extension is negotiated in SSL 3.0, the master secret is
	computed as
	master_secret =		This design reflects the recommendation that keys should be bound to
	MD5(pre_master_secret + SHA('A' + pre_master_secret +		the security contexts that compute them [sp800-108]. The technique
	session_hash)) +		of mixing a hash of the key exchange messages into master key
	MD5(pre_master_secret + SHA('BB' + pre_master_secret +		derivation is already used in other well-known protocols such as SSH
	session_hash)) +		[RFC4251].
	MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
	session_hash));
	That is, the "session_hash" replaces the concatenation of		Clients and servers SHOULD NOT resume sessions that do not use the
	"ClientHello.random" and "ServerHello.random".		extended master secret, especially if they rely on features like
			compound authentication that fall into the vulnerable cases described
			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 client and server agree on this extension and a full handshake
	takes place, both client and server MUST use the extended master		takes place, both client and server MUST use the extended master
	secret derivation algorithm, as defined in Section 4.		secret derivation algorithm, as defined in Section 4.
			If an abbreviated handshake takes place, the extension has no effect.
			The resumed session is protected by the extended master secret if the
			extension was negotiated in the full handshake that generated the
			session.
	5.2. Client and Server Behavior		5.2. Client and Server Behavior
	In its ClientHello message, a client implementing this document MUST		In its ClientHello message, a client implementing this document MUST
	send the "extended_master_secret" extension.		send the "extended_master_secret" extension.
	If a server receives the "extended_master_secret" extension, it MUST		If a server implementing this document receives the
	include the "extended_master_secret" extension in its ServerHello		"extended_master_secret" extension, it MUST include the
	message.		"extended_master_secret" extension in its ServerHello message.
	Implementation note: if the server decides to proceed with
	resumption, the extension does not have any effect. Requiring the
	extension to be included anyway makes the extension negotiation logic
	easier, because it does not depend on whether resumption is accepted
	or not. Moreover, a client may find useful to learn that the server
	supports this extension anyway.
	6. Security Considerations		6. Security Considerations
	This entire document is about security, see [TRIPLE-HS] for more		6.1. Triple Handshake Preconditions and Impact
	details.
			One way to mount a triple handshake attack has been described in
			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
			in [TRIPLE-HS]. Here, some further discussion is presented about
			attack preconditions and impact.
			To mount a triple handshake attack, it must be possible to force the
			same master secret on two different sessions. For this to happen,
			two preconditions must be met:
			o The client, C, must be willing to connect to a malicious server,
			A. In certain contexts, like the web, this can be easily
			achieved, since a browser can be instructed to load content from
			an untrusted origin.
			o The pre-master secret must be synchronized on the two sessions.
			This is particularly easy to achieve with the RSA key exchange,
			but arbitrary DH groups or ECDH curves can be exploited to this
			effect as well.
			Once the master secret is synchronized on two sessions, any security
			property that relies on the uniqueness of the master secret is
			compromised. For example, a TLS exporter [RFC5705] no longer
			provides a unique key bound to the current session.
			TLS session resumption also relies on the uniqueness of the master
			secret to authenticate the resuming peers. Hence, if a synchronized
			session is resumed, the peers cannot be sure about each other
			identity, and the attacker knows the connection keys. Clearly, a
			precondition to this step of the attack is that both client and
			server support session resumption (either via session identifier or
			session tickets [RFC5077]).
			Additionally, in a synchronized abbreviated handshake, the whole
			transcript is synchronized, which includes the "verify_data" values.
			So, after an abbreviated handshake, channel bindings like "tls-
			unique" [RFC5929] will not identify uniquely the connection anymore.
			Synchronization of the "verify_data" in abbreviated handshakes also
			undermines the security guarantees of the renegotiation indication
			extension [RFC5746], re-enabling a prefix-injection flaw similar to
			the renegotiation attack [Ray09]. However, in a triple handshake
			attack, the client sees the server certificate changing across
			different full handshakes. Hence, a precondition to mount this stage
			of the attack is that the client accepts different certificates at
			each handshake, even if their common names do not match. Before the
			triple handshake attack was discovered, this used to be widespread
			behavior, at least among some web browsers, that where hence
			vulnerable to the attack.
			The extended master secret extension thwarts triple handshake attacks
			at their first stage, by ensuring that different sessions necessarily
			end up with different master secret values. Hence, all security
			properties relying on the uniqueness of the master secret are now
			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
			its channel bindings, and to allow for certificate changes across
			renegotiation, meaning that all certificates are controlled by the
			same peer.
			6.2. Cryptographic Properties of the Hash Function
			The session hashes of two different sessions need to be distinct,
			hence the "Hash" function used to compute the "session_hash" needs to
			be collision resistant. As such, hash functions such as MD5 or SHA1
			are NOT RECOMMENDED.
			We observe that the "Hash" function used in the Finished message
			computation already needs to be collision resistant, for the
			renegotiation indication extension [RFC5746] to work: a collision on
			the verify_data (and hence on the hash function computing the
			handshake messages hash) defeats the renegotiation indication
			countermeasure.
			As a matter of fact, all current ciphersuites defined for TLS 1.2 use
			SHA256 or better. For earlier versions 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.
			6.3. Session Hash Handshake Coverage
			The "session_hash" is designed to encompass all relevant session
			information, including ciphersuite negotiation, key exchange messages
			and client and server identities.
			This document sets the "session_hash" to cover all handshake messages
			up to and including the ClientKeyExchange. In this way, on one hand,
			all the relevant session information is included; on the other hand,
			the master secret can be computed right after the ClientKeyExchange
			message, allowing implementations to shred the pre-master secret from
			memory as soon as possible.
			It is crucial that any message sent after the ClientKeyExchange does
			not alter the session information. This is the case for the Finished
			messages, as well as for the client CertificateVerify in client-
			authenticated sessions. This also applies to session ticket messages
			[RFC5077]. Any protocol extension that adds protocol messages after
			the Client Key Exchange MUST either ensure that such messages do not
			alter the session information, or it MUST analyze the impact of the
			protocol changes with respect to the handshake coverage of the
			session hash.
			6.4. No SSL 3.0 Support
			SSL 3.0 [RFC6101] is a predecessor of the TLS protocol, and it is
			equally vulnerable to the triple handshake attacks.
			The use of extensions precludes use of the extended master secret
			with SSL 3.0. Yet, this protocol uses encryption schemes and
			algorithms that are now considered weak. Furthermore, it seems
			likely that any system that did not upgrate from SSL 3.0 to any later
			version of TLS will be exposed to several other vulnerabilties
			anyway. As a consequence, this document does not provide workarounds
			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 for 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
	Laurie, Eric Rescorla, Martin Rex, Brian Smith.		Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric
			Rescorla, Martin Rex, Brian Smith.
	9. References		9. References
	9.1. Normative References		9.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.
	[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.
	skipping to change at page 8, line 23 ¶		skipping to change at page 10, line 11 ¶
	[RFC5705] Rescorla, E., "Keying Material Exporters for Transport		[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
	Layer Security (TLS)", RFC 5705, March 2010.		Layer Security (TLS)", RFC 5705, March 2010.
	[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings		[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
	for TLS", RFC 5929, July 2010.		for TLS", RFC 5929, July 2010.
	[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)		[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
	Protocol Architecture", RFC 4251, January 2006.		Protocol Architecture", RFC 4251, January 2006.
			[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
			"Transport Layer Security (TLS) Session Resumption without
			Server-Side State", RFC 5077, January 2008.
			[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
			Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
			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, pages 98-113 , 2014.
	[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", Unpublished draft , 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
	Email: karthikeyan.bhargavan@inria.fr		Email: karthikeyan.bhargavan@inria.fr
End of changes. 21 change blocks.
	93 lines changed or deleted		190 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/