< draft-ietf-tls-session-hash-01.txt		draft-ietf-tls-session-hash-02.txt >
	Network Working Group K. Bhargavan		Network Working Group K. Bhargavan
	Internet-Draft A. Delignat-Lavaud		Internet-Draft A. Delignat-Lavaud
	Expires: February 23, 2015 A. Pironti		Expires: April 9, 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.
	August 22, 2014		October 6, 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-01		draft-ietf-tls-session-hash-02
	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 session resumption, becomes vulnerable		for authentication, including session resumption, becomes vulnerable
	skipping to change at page 1, line 46 ¶		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 February 23, 2015.		This Internet-Draft will expire on April 9, 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 26 ¶		skipping to change at page 2, line 26 ¶
	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
			4.2. SSL 3.0 . . . . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 7		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	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];
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 40 ¶
	"pre_master_secret" is available, typically immediately before or		"pre_master_secret" is available, typically immediately before or
	after sending the Client Key Exchange message. The definition of		after sending the Client Key Exchange message. The definition of
	"session_hash" given in this document requires minimal patches to		"session_hash" given in this document requires minimal patches to
	such implementations in order to implement the extended master secret		such implementations in order to implement the extended master secret
	extension. Our definition is also compatible with the common		extension. Our definition is also compatible with the common
	implementation practice of keeping running hashes of the handshake		implementation practice of keeping running hashes of the handshake
	log.		log.
	4. The extended master secret		4. The extended master secret
	When the extended master secret extension is negotiated, the		4.1. TLS
	"master_secret" is computed as
	master_secret = PRF(pre_master_secret, "extended master secret",		When the extended master secret extension is negotiated in a TLS
	session_hash)		session, the "master_secret" is computed as
	[0..47];
			master_secret = PRF(pre_master_secret, "extended master secret",
			session_hash)
			[0..47];
			The extended master secret computation differs from the [RFC5246] in
			the following ways:
			o The "extended master secret" label is used instead of "master
			secret";
			o The "session_hash" is used instead of the "ClientHello.random" and
			"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, client and server certificates. Consequently, the
	extended master secret depends upon the choice of all these session		extended master secret depends upon the choice of all these session
	parameters.		parameters.
	Our proposed design reflects the recommendation that keys should be		Our proposed design reflects the recommendation that keys should be
	bound to the security contexts that compute them [sp800-108]. The		bound to the security contexts that compute them [sp800-108]. The
	technique of mixing a hash of the key exchange messages into master		technique of mixing a hash of the key exchange messages into master
	key derivation is already used in other well-known protocols such as		key derivation is already used in other well-known protocols such as
	SSH [RFC4251].		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 =
			MD5(pre_master_secret + SHA('A' + pre_master_secret +
			session_hash)) +
			MD5(pre_master_secret + SHA('BB' + pre_master_secret +
			session_hash)) +
			MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
			session_hash));
			That is, the "session_hash" replaces the concatenation of
			"ClientHello.random" and "ServerHello.random".
	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 TBA), 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 XX XX 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.
	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.
	skipping to change at page 6, line 48 ¶		skipping to change at page 7, line 32 ¶
	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
	This entire document is about security, see [TRIPLE-HS] for more		This entire document is about security, see [TRIPLE-HS] for more
	details.		details.
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to assign an extension code point for the		IANA has added the extension code point 23 (0x0017), which has been
	extended_master_secret extension to the TLS ExtensionType values		used for prototype implementations, for the "extended_master_secret"
	registry as specified in TLS [RFC5246].		extension to the TLS ExtensionType values registry as specified in
			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, Eric Rescorla, Martin Rex, Brian Smith.
End of changes. 14 change blocks.
	18 lines changed or deleted		51 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/