< draft-bhargavan-tls-session-hash-00.txt		draft-bhargavan-tls-session-hash-01.txt >
	Network Working Group K. Bhargavan		Network Working Group K. Bhargavan
	Internet-Draft A. Delignat-Lavaud		Internet-Draft A. Delignat-Lavaud
	Expires: October 20, 2014 A. Pironti		Expires: January 22, 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.
	April 18, 2014		July 21, 2014
	Transport Layer Security (TLS) Session Hash and		Transport Layer Security (TLS) Session Hash and
	Extended Master Secret Extension		Extended Master Secret Extension
	draft-bhargavan-tls-session-hash-00		draft-bhargavan-tls-session-hash-01
	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 such as the
	client and server identities. Consequently, it is possible for an		client and server identities. Consequently, it is possible for an
	active attacker to set up two sessions, one with a client and another		active attacker to set up two sessions, one with a client and another
	with a server such that the master secrets on the two sessions are		with a server such that the master secrets on the two sessions are
	the same. Thereafter, any mechanism that relies on the master secret		the same. Thereafter, any mechanism that relies on the master secret
	for authentication, including renegotiation after session resumption,		for authentication, including renegotiation after session resumption,
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 October 20, 2014.		This Internet-Draft will expire on January 22, 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 28 ¶		skipping to change at page 2, line 28 ¶
	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
	5. Extension negotiation . . . . . . . . . . . . . . . . . . . . 6		5. Extension negotiation . . . . . . . . . . . . . . . . . . . . 6
	5.1. Extension definition . . . . . . . . . . . . . . . . . . 6		5.1. Extension definition . . . . . . . . . . . . . . . . . . 6
	5.2. Extended Master Secret Signaling Cipher Suite Value . . . 6		5.2. Client and Server Behavior . . . . . . . . . . . . . . . 6
	5.3. Client and Server Behavior . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Acknowdledgements . . . . . . . . . . . . . . . . . . . . . . 6
	7. Acknowdledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	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 malicious server, A. A then connects to a
	server, S, and completes both handshakes. For simplicity, assume		server, S, and completes both handshakes. For simplicity, assume
	that C and S only use RSA ciphersuites. (Note that C thinks it is		that C and S only use RSA ciphersuites. (Note that C thinks it is
	connecting to A and is oblivious of S's involvement.)		connecting to A and is oblivious of S's involvement.)
	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 onw certificate chain and sends it to C.		A replaces it with its onw 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 connection (between C and A, and between A and S)		At this point, both connection (between C and A, and between A and S)
	have new sessions that share the same "pre_master_secret",		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. Moreover, the record keys on the two
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 11 ¶
	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 occurences are called unknown key-		the key exchange literature, such occurences 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 itself, these attacks do not		their secret is shared only with A. In itself, these attacks do not
	break integrity or confidentiality between honest parties, but they		break integrity or confidentiality between honest parties, but they
	offer a useful starting point from which to mount impersonation		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
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	This document defines a new TLS extension, "extended_master_secret"		This document defines a new TLS extension, "extended_master_secret"
	(with extension type TBA), which is used to signal both client and		(with extension type TBA), 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 XX XX 00 00.		encoding of the extension is XX XX 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.
	5.2. Extended Master Secret Signaling Cipher Suite Value		5.2. Client and Server Behavior
	To maximize backward compatibility, since the
	"extended_master_secret" is indeed a signaling extension, a special
	Signaling Cipher Suite Value (SCSV) "TLS_EXTENDED_MASTER_SECRET",
	with code point {TBA}, is defined.
	5.3. Client and Server Behavior
	In its ClientHello message, a client MUST either send the		In its ClientHello message, a client implementing this document MUST
	"extended_master_secret" extension, or the		send the "extended_master_secret" extension.
	"TLS_EXTENDED_MASTER_SECRET" SCSV. Clients SHOULD NOT include both.
	If a server receives either the "extended_master_secret" extension,		If a server receives the "extended_master_secret" extension, it MUST
	or the "TLS_EXTENDED_MASTER_SECRET" SCSV, it MUST include the		include the "extended_master_secret" extension in its ServerHello
	"extended_master_secret" extension in its ServerHello message.		message.
	Implementation note: if the server decides to proceed with		Implementation note: if the server decides to proceed with
	resumption, the extension does not have any effect. Requiring the		resumption, the extension does not have any effect. Requiring the
	extension to be included anyway makes the extension negotiation logic		extension to be included anyway makes the extension negotiation logic
	easier, because it does not depend on whether resumption is accepted		easier, because it does not depend on whether resumption is accepted
	or not. Moreover, a client may find useful to learn that the server		or not. Moreover, a client may find useful to learn that the server
	supports this extension anyway.		supports this extension anyway.
	6. Security Considerations		6. Security Considerations
End of changes. 14 change blocks.
	28 lines changed or deleted		19 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/