< draft-mavrogiannopoulos-tls-cross-protocol-02.txt		draft-mavrogiannopoulos-tls-cross-protocol-03.txt >
	Network Working Group N. Mavrogiannopoulos		Network Working Group N. Mavrogiannopoulos
	Internet-Draft KU Leuven - IBBT		Internet-Draft B. Preneel
	Intended status: Standards Track November 5, 2012		Intended status: Standards Track KU Leuven - IBBT
	Expires: May 9, 2013		Expires: May 13, 2013 November 9, 2012
	Preventing cross-protocol attacks on the TLS protocol		Preventing cross-protocol attacks on the TLS protocol
	draft-mavrogiannopoulos-tls-cross-protocol-02		draft-mavrogiannopoulos-tls-cross-protocol-03
	Abstract		Abstract
	This memo proposes a fix in the TLS key exchange signature generation		This memo proposes a fix in the TLS key exchange signature generation
	to prevent cross-protocol attacks.		to prevent cross-protocol 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.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	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 9, 2013.		This Internet-Draft will expire on May 13, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 46 ¶		skipping to change at page 2, line 46 ¶
	The goal of this memo is to restrict the applicability of the server		The goal of this memo is to restrict the applicability of the server
	provided signed ServerKeyExchange to the current session. A simple		provided signed ServerKeyExchange to the current session. A simple
	fix may be to include the negotiated ciphersuite into the signature.		fix may be to include the negotiated ciphersuite into the signature.
	However, the TLS protocol is complex and a key exchange method does		However, the TLS protocol is complex and a key exchange method does
	not always imply a single format of the ServerKeyExchange signature.		not always imply a single format of the ServerKeyExchange signature.
	For example, the elliptic curves key exchange method may be used with		For example, the elliptic curves key exchange method may be used with
	an arbitrary elliptic curve [RFC4492] which requires different data		an arbitrary elliptic curve [RFC4492] which requires different data
	in the ServerKeyExchange than when used with a named curve. Such key		in the ServerKeyExchange than when used with a named curve. Such key
	exchange suboptions are negotiated using TLS extensions and such		exchange suboptions are negotiated using TLS extensions and such
	extensions should be covered by the signature, to prevent any attack		extensions should be covered by the signature to prevent any attack
	that takes advantage of the different signature format.		that takes advantage of the different signature format.
	For that we propose that the signature of the ServerKeyExchange		For that we propose that the signature of the ServerKeyExchange
	message to be modified to include in addition to explicit identifiers		message to be modified to include in addition to explicit identifiers
	of the algorithms, all the previously exchanged messages. The		of the algorithms, all the previously exchanged messages. The
	proposed signature for a ServerKeyExchange message is shown below.		proposed signature for a ServerKeyExchange message is shown below.
	enum { server (0), client (1) } ConnectionEnd;		enum { server (0), client (1) } ConnectionEnd;
	enum { dhe_dss (0), dhe_rsa (1),		enum { dhe_dss (0), dhe_rsa (1),
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 32 ¶
	struct {		struct {
	Parameters params;		Parameters params;
	digitally-signed struct {		digitally-signed struct {
	ConnectionEnd entity;		ConnectionEnd entity;
	Parameters params;		Parameters params;
	opaque handshake_messages<0..2^24-1>;		opaque handshake_messages<0..2^24-1>;
	}		}
	} ServerKeyExchange;		} ServerKeyExchange;
	The new format includes explicit indicators of the entity (server),		The new format includes explicit indicators of the entity (server),
	the key exchange algorithm used, the handshake messages exchanged,		the key exchange algorithm used, the parameters of the key exchange,
	and the parameters of the key exchange. This modification will be		and the previously exchanged handshake messages. This modification
	negotiated by using a new TLS extension to allow backwards		will be negotiated by using a new TLS extension to allow backwards
	compatibility.		compatibility.
	4. The extension		4. The extension
	In order for a client to advertise its support for the new		In order for a client to advertise its support for the new
	ServerKeyExchange format we add a new extension		ServerKeyExchange format we add a new extension
	"new_server_key_exchange", with value TBD-BY-IANA, to the enumerated		"new_server_key_exchange", with value TBD-BY-IANA, to the enumerated
	ExtensionType defined in [RFC5246]. The "extension_data" field of		ExtensionType defined in [RFC5246]. The "extension_data" field of
	this extension is empty.		this extension is empty.
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	[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",		Sockets Layer (SSL) Protocol Version 3.0",
	RFC 6101, August 2011.		RFC 6101, August 2011.
	[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,		[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,
	and B. Moeller, "Elliptic Curve Cryptography (ECC)		and B. Moeller, "Elliptic Curve Cryptography (ECC)
	Cipher Suites for Transport Layer Security (TLS)",		Cipher Suites for Transport Layer Security (TLS)",
	RFC 4492, May 2006.		RFC 4492, May 2006.
	Author's Address		Authors' Addresses
	Nikos Mavrogiannopoulos		Nikos Mavrogiannopoulos
	KU Leuven ESAT/SCD/COSIC - IBBT		KU Leuven ESAT/SCD/COSIC
	Kasteelpark Arenberg 10, bus 2446		Kasteelpark Arenberg 10, bus 2446
	Leuven-Heverlee, B-3001		Leuven-Heverlee, B-3001
	Belgium		Belgium
	EMail: nikos.mavrogiannopoulos@esat.kuleuven.be		EMail: nikos.mavrogiannopoulos@esat.kuleuven.be
			Bart Preneel
			KU Leuven ESAT/SCD/COSIC
			Kasteelpark Arenberg 10, bus 2446
			Leuven-Heverlee, B-3001
			Belgium
			EMail: bart.preneel@esat.kuleuven.be
End of changes. 8 change blocks.
	11 lines changed or deleted		11 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/