< draft-ietf-tls-rfc4492bis-00.txt		draft-ietf-tls-rfc4492bis-01.txt >
	TLS Working Group Y. Nir		TLS Working Group Y. Nir
	Internet-Draft Check Point		Internet-Draft Check Point
	Intended status: Standards Track December 2, 2014		Intended status: Standards Track January 13, 2015
	Expires: June 5, 2015		Expires: July 17, 2015
	Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer		Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
	Security (TLS) Versions 1.2 and Earlier		Security (TLS) Versions 1.2 and Earlier
	draft-ietf-tls-rfc4492bis-00		draft-ietf-tls-rfc4492bis-01
	Abstract		Abstract
	This document describes key exchange algorithms based on Elliptic		This document describes key exchange algorithms based on Elliptic
	Curve Cryptography (ECC) for the Transport Layer Security (TLS)		Curve Cryptography (ECC) for the Transport Layer Security (TLS)
	protocol. In particular, it specifies the use of Elliptic Curve		protocol. In particular, it specifies the use of Ephemeral Elliptic
	Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of		Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
	Elliptic Curve Digital Signature Algorithm (ECDSA) as a new		use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
	authentication mechanism.		authentication mechanism.
	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 June 5, 2015.		This Internet-Draft will expire on July 17, 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
	1.1. Conventions Used in This Document . . . . . . . . . . . . 4		1.1. Conventions Used in This Document . . . . . . . . . . . . 4
	2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 4		2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 4
	2.1. ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3. ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6		2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.4. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Client Authentication . . . . . . . . . . . . . . . . . . . . 6
	2.5. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Client Authentication . . . . . . . . . . . . . . . . . . . . 7		4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 7
	3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 8		5. Data Structures and Computations . . . . . . . . . . . . . . 8
	3.2. ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . 8		5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8
	3.3. RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 9		5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 10
	4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 9		5.1.2. Supported Point Formats Extension . . . . . . . . . . 11
	5. Data Structures and Computations . . . . . . . . . . . . . . 10		5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 12
	5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 10		5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 13
	5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 12		5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 14
	5.1.2. Supported Point Formats Extension . . . . . . . . . . 13		5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 18
	5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 14		5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 19
	5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 15		5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 20
	5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 16		5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 22
	5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 20		5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 23
	5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 21		5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 23
	5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 22		6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 24
	5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 24		7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 25		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 25		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 26		10. Version History for This Draft . . . . . . . . . . . . . . . 26
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 27		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		11.1. Normative References . . . . . . . . . . . . . . . . . . 26
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28		11.2. Informative References . . . . . . . . . . . . . . . . . 28
	10. Version History for This Draft . . . . . . . . . . . . . . . 28		Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 28
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29		Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 29
	11.1. Normative References . . . . . . . . . . . . . . . . . . 29		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
	11.2. Informative References . . . . . . . . . . . . . . . . . 30
	Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 30
	Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 31
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	Elliptic Curve Cryptography (ECC) is emerging as an attractive		Elliptic Curve Cryptography (ECC) is emerging as an attractive
	public-key cryptosystem, in particular for mobile (i.e., wireless)		public-key cryptosystem, in particular for mobile (i.e., wireless)
	environments. Compared to currently prevalent cryptosystems such as		environments. Compared to currently prevalent cryptosystems such as
	RSA, ECC offers equivalent security with smaller key sizes. This is		RSA, ECC offers equivalent security with smaller key sizes. This is
	illustrated in the following table, based on [Lenstra_Verheul], which		illustrated in the following table, based on [Lenstra_Verheul], which
	gives approximate comparable key sizes for symmetric- and asymmetric-		gives approximate comparable key sizes for symmetric- and asymmetric-
	key cryptosystems based on the best-known algorithms for attacking		key cryptosystems based on the best-known algorithms for attacking
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 29 ¶
	Smaller key sizes result in savings for power, memory, bandwidth, and		Smaller key sizes result in savings for power, memory, bandwidth, and
	computational cost that make ECC especially attractive for		computational cost that make ECC especially attractive for
	constrained environments.		constrained environments.
	This document describes additions to TLS to support ECC, applicable		This document describes additions to TLS to support ECC, applicable
	to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246]. The		to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246]. The
	use of ECC in TLS 1.3 is defined in [I-D.ietf-tls-tls13], and is		use of ECC in TLS 1.3 is defined in [I-D.ietf-tls-tls13], and is
	explicitly out of scope for this document. In particular, this		explicitly out of scope for this document. In particular, this
	document defines:		document defines:
	o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement		o the use of the Elliptic Curve Diffie-Hellman key agreement scheme
	scheme with long-term or ephemeral keys to establish the TLS		with ephemeral keys to establish the TLS premaster secret, and
	premaster secret, and		o the use of ECDSA certificates for authentication of TLS peers.
	o the use of fixed-ECDH certificates and ECDSA for authentication of
	TLS peers.
	The remainder of this document is organized as follows. Section 2		The remainder of this document is organized as follows. Section 2
	provides an overview of ECC-based key exchange algorithms for TLS.		provides an overview of ECC-based key exchange algorithms for TLS.
	Section 3 describes the use of ECC certificates for client		Section 3 describes the use of ECC certificates for client
	authentication. TLS extensions that allow a client to negotiate the		authentication. TLS extensions that allow a client to negotiate the
	use of specific curves and point formats are presented in Section 4.		use of specific curves and point formats are presented in Section 4.
	Section 5 specifies various data structures needed for an ECC-based		Section 5 specifies various data structures needed for an ECC-based
	handshake, their encoding in TLS messages, and the processing of		handshake, their encoding in TLS messages, and the processing of
	those messages. Section 6 defines ECC-based cipher suites and		those messages. Section 6 defines ECC-based cipher suites and
	identifies a small subset of these as recommended for all		identifies a small subset of these as recommended for all
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 13 ¶
	TLS extensions [RFC4366], and ECC (TBD: reference Wikipedia here?).		TLS extensions [RFC4366], and ECC (TBD: reference Wikipedia here?).
	1.1. Conventions Used in This Document		1.1. Conventions Used in This Document
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Key Exchange Algorithm		2. Key Exchange Algorithm
	This document introduces five new ECC-based key exchange algorithms		This document defines three new ECC-based key exchange algorithms for
	for TLS. All of them use ECDH to compute the TLS premaster secret,		TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS
	and they differ only in the lifetime of ECDH keys (long-term or		premaster secret, and they differ only in the mechanism (if any) used
	ephemeral) and the mechanism (if any) used to authenticate them. The		to authenticate them. The derivation of the TLS master secret from
	derivation of the TLS master secret from the premaster secret and the		the premaster secret and the subsequent generation of bulk
	subsequent generation of bulk encryption/MAC keys and initialization		encryption/MAC keys and initialization vectors is independent of the
	vectors is independent of the key exchange algorithm and not impacted		key exchange algorithm and not impacted by the introduction of ECC.
	by the introduction of ECC.
	The table below summarizes the new key exchange algorithms, which		The table below summarizes the new key exchange algorithms, which
	mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon, respectively.		mimic DHE_DSS, DHE_RSA, and DH_anon, respectively.
	+-------------+--------------------------------------------+		+-------------+---------------------------------------+
	| Algorithm | Description |		| Algorithm | Description |
	+-------------+--------------------------------------------+		+-------------+---------------------------------------+
	| ECDH_ECDSA | Fixed ECDH with ECDSA-signed certificates. |		| ECDHE_ECDSA | Ephemeral ECDH with ECDSA signatures. |
	| ECDHE_ECDSA | Ephemeral ECDH with ECDSA signatures. |		| ECDHE_RSA | Ephemeral ECDH with RSA signatures. |
	| ECDH_RSA | Fixed ECDH with RSA-signed certificates. |		| ECDH_anon | Anonymous ECDH, no signatures. |
	| ECDHE_RSA | Ephemeral ECDH with RSA signatures. |		+-------------+---------------------------------------+
	| ECDH_anon | Anonymous ECDH, no signatures. |
	+-------------+--------------------------------------------+
	Table 2: ECC Key Exchange Algorithms		Table 2: ECC Key Exchange Algorithms
	The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward		The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
	secrecy. With ECDHE_RSA, a server can reuse its existing RSA		secrecy. With ECDHE_RSA, a server can reuse its existing RSA
	certificate and easily comply with a constrained client's elliptic		certificate and easily comply with a constrained client's elliptic
	curve preferences (see Section 4). However, the computational cost		curve preferences (see Section 4). However, the computational cost
	incurred by a server is higher for ECDHE_RSA than for the traditional		incurred by a server is higher for ECDHE_RSA than for the traditional
	RSA key exchange, which does not provide forward secrecy.		RSA key exchange, which does not provide forward secrecy.
	The ECDH_RSA mechanism requires a server to acquire an ECC
	certificate, but the certificate issuer can still use an existing RSA
	key for signing. This eliminates the need to update the keys of
	trusted certification authorities accepted by TLS clients. The
	ECDH_ECDSA mechanism requires ECC keys for the server as well as the
	certification authority and is best suited for constrained devices
	unable to support RSA.
	The anonymous key exchange algorithm does not provide authentication		The anonymous key exchange algorithm does not provide authentication
	of the server or the client. Like other anonymous TLS key exchanges,		of the server or the client. Like other anonymous TLS key exchanges,
	it is subject to man-in-the-middle attacks. Implementations of this		it is subject to man-in-the-middle attacks. Implementations of this
	algorithm SHOULD provide authentication by other means.		algorithm SHOULD provide authentication by other means.
	Note that there is no structural difference between ECDH and ECDSA		Note that there is no structural difference between ECDH and ECDSA
	keys. A certificate issuer may use X.509 v3 keyUsage and		keys. A certificate issuer may use X.509 v3 keyUsage and
	extendedKeyUsage extensions to restrict the use of an ECC public key		extendedKeyUsage extensions to restrict the use of an ECC public key
	to certain computations. This document refers to an ECC key as ECDH-		to certain computations. This document refers to an ECC key as ECDH-
	capable if its use in ECDH is permitted. ECDSA-capable is defined		capable if its use in ECDH is permitted. ECDSA-capable is defined
	skipping to change at page 6, line 5 ¶		skipping to change at page 5, line 39 ¶
	only on the ClientHello, the ServerHello, the server's Certificate		only on the ClientHello, the ServerHello, the server's Certificate
	message, the ServerKeyExchange, the ClientKeyExchange, the		message, the ServerKeyExchange, the ClientKeyExchange, the
	CertificateRequest, the client's Certificate message, and the		CertificateRequest, the client's Certificate message, and the
	CertificateVerify. Next, we describe each ECC key exchange algorithm		CertificateVerify. Next, we describe each ECC key exchange algorithm
	in greater detail in terms of the content and processing of these		in greater detail in terms of the content and processing of these
	messages. For ease of exposition, we defer discussion of client		messages. For ease of exposition, we defer discussion of client
	authentication and associated messages (identified with a + in		authentication and associated messages (identified with a + in
	Figure 1) until Section 3 and of the optional ECC-specific extensions		Figure 1) until Section 3 and of the optional ECC-specific extensions
	(which impact the Hello messages) until Section 4.		(which impact the Hello messages) until Section 4.
	2.1. ECDH_ECDSA		2.1. ECDHE_ECDSA
	In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
	public key and be signed with ECDSA.
	A ServerKeyExchange MUST NOT be sent (the server's certificate
	contains all the necessary keying information required by the client
	to arrive at the premaster secret).
	The client generates an ECDH key pair on the same curve as the
	server's long-term public key and sends its public key in the
	ClientKeyExchange message (except when using client authentication
	algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
	modifications from Section 3.2 or Section 3.3.
	Both client and server perform an ECDH operation and use the
	resultant shared secret as the premaster secret. All ECDH
	calculations are performed as specified in Section 5.10.
	2.2. ECDHE_ECDSA
	In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-		In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
	capable public key and be signed with ECDSA.		capable public key and be signed with ECDSA.
	The server sends its ephemeral ECDH public key and a specification of		The server sends its ephemeral ECDH public key and a specification of
	the corresponding curve in the ServerKeyExchange message. These		the corresponding curve in the ServerKeyExchange message. These
	parameters MUST be signed with ECDSA using the private key		parameters MUST be signed with ECDSA using the private key
	corresponding to the public key in the server's Certificate.		corresponding to the public key in the server's Certificate.
	The client generates an ECDH key pair on the same curve as the		The client generates an ECDH key pair on the same curve as the
	server's ephemeral ECDH key and sends its public key in the		server's ephemeral ECDH key and sends its public key in the
	ClientKeyExchange message.		ClientKeyExchange message.
	Both client and server perform an ECDH operation Section 5.10 and use		Both client and server perform an ECDH operation Section 5.10 and use
	the resultant shared secret as the premaster secret.		the resultant shared secret as the premaster secret.
	2.3. ECDH_RSA		2.2. ECDHE_RSA
	This key exchange algorithm is the same as ECDH_ECDSA except that the
	server's certificate MUST be signed with RSA rather than ECDSA.
	2.4. ECDHE_RSA
	This key exchange algorithm is the same as ECDHE_ECDSA except that		This key exchange algorithm is the same as ECDHE_ECDSA except that
	the server's certificate MUST contain an RSA public key authorized		the server's certificate MUST contain an RSA public key authorized
	for signing, and that the signature in the ServerKeyExchange message		for signing, and that the signature in the ServerKeyExchange message
	must be computed with the corresponding RSA private key. The server		must be computed with the corresponding RSA private key. The server
	certificate MUST be signed with RSA.		certificate MUST be signed with RSA.
	2.5. ECDH_anon		2.3. ECDH_anon
	In ECDH_anon, the server's Certificate, the CertificateRequest, the		In ECDH_anon, the server's Certificate, the CertificateRequest, the
	client's Certificate, and the CertificateVerify messages MUST NOT be		client's Certificate, and the CertificateVerify messages MUST NOT be
	sent.		sent.
	The server MUST send an ephemeral ECDH public key and a specification		The server MUST send an ephemeral ECDH public key and a specification
	of the corresponding curve in the ServerKeyExchange message. These		of the corresponding curve in the ServerKeyExchange message. These
	parameters MUST NOT be signed.		parameters MUST NOT be signed.
	The client generates an ECDH key pair on the same curve as the		The client generates an ECDH key pair on the same curve as the
	server's ephemeral ECDH key and sends its public key in the		server's ephemeral ECDH key and sends its public key in the
	ClientKeyExchange message.		ClientKeyExchange message.
	Both client and server perform an ECDH operation and use the		Both client and server perform an ECDH operation and use the
	resultant shared secret as the premaster secret. All ECDH		resultant shared secret as the premaster secret. All ECDH
	calculations are performed as specified in Section 5.10.		calculations are performed as specified in Section 5.10.
	Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA		Note that while the ECDHE_ECDSA and ECDHE_RSA key exchange algorithms
	key exchange algorithms require the server's certificate to be signed		require the server's certificate to be signed with a particular
	with a particular signature scheme, this specification (following the		signature scheme, this specification (following the similar cases of
	similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in the TLS base		DHE_DSS, and DHE_RSA in the TLS base documents) does not impose
	documents) does not impose restrictions on signature schemes used		restrictions on signature schemes used elsewhere in the certificate
	elsewhere in the certificate chain. (Often such restrictions will be		chain. (Often such restrictions will be useful, and it is expected
	useful, and it is expected that this will be taken into account in		that this will be taken into account in certification authorities'
	certification authorities' signing practices. However, such		signing practices. However, such restrictions are not strictly
	restrictions are not strictly required in general: Even if it is		required in general: Even if it is beyond the capabilities of a
	beyond the capabilities of a client to completely validate a given		client to completely validate a given chain, the client may be able
	chain, the client may be able to validate the server's certificate by		to validate the server's certificate by relying on a trusted
	relying on a trusted certification authority whose certificate		certification authority whose certificate appears as one of the
	appears as one of the intermediate certificates in the chain.)		intermediate certificates in the chain.)
	3. Client Authentication		3. Client Authentication
	This document defines three new client authentication mechanisms,		This document defines a client authentication mechanism, named after
	each named after the type of client certificate involved: ECDSA_sign,		the type of client certificate involved: ECDSA_sign. The ECDSA_sign
	ECDSA_fixed_ECDH, and RSA_fixed_ECDH. The ECDSA_sign mechanism is		mechanism is usable with any of the non-anonymous ECC key exchange
	usable with any of the non-anonymous ECC key exchange algorithms		algorithms described in Section 2 as well as other non-anonymous
	described in Section 2 as well as other non-anonymous (non-ECC) key		(non-ECC) key exchange algorithms defined in TLS.
	exchange algorithms defined in TLS. The ECDSA_fixed_ECDH and
	RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
	Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
	use of a long-term ECDH client key would jeopardize the forward
	secrecy property of these algorithms.
	The server can request ECC-based client authentication by including		The server can request ECC-based client authentication by including
	one or more of these certificate types in its CertificateRequest		this certificate type in its CertificateRequest message. The client
	message. The server must not include any certificate types that are		must check if it possesses a certificate appropriate for the method
	prohibited for the negotiated key exchange algorithm. The client		suggested by the server and is willing to use it for authentication.
	must check if it possesses a certificate appropriate for any of the
	methods suggested by the server and is willing to use it for
	authentication.
	If these conditions are not met, the client should send a client		If these conditions are not met, the client should send a client
	Certificate message containing no certificates. In this case, the		Certificate message containing no certificates. In this case, the
	ClientKeyExchange should be sent as described in Section 2, and the		ClientKeyExchange should be sent as described in Section 2, and the
	CertificateVerify should not be sent. If the server requires client		CertificateVerify should not be sent. If the server requires client
	authentication, it may respond with a fatal handshake failure alert.		authentication, it may respond with a fatal handshake failure alert.
	If the client has an appropriate certificate and is willing to use it		If the client has an appropriate certificate and is willing to use it
	for authentication, it must send that certificate in the client's		for authentication, it must send that certificate in the client's
	Certificate message (as per Section 5.6) and prove possession of the		Certificate message (as per Section 5.6) and prove possession of the
	skipping to change at page 8, line 36 ¶		skipping to change at page 7, line 39 ¶
	3.1. ECDSA_sign		3.1. ECDSA_sign
	To use this authentication mechanism, the client MUST possess a		To use this authentication mechanism, the client MUST possess a
	certificate containing an ECDSA-capable public key and signed with		certificate containing an ECDSA-capable public key and signed with
	ECDSA.		ECDSA.
	The client proves possession of the private key corresponding to the		The client proves possession of the private key corresponding to the
	certified key by including a signature in the CertificateVerify		certified key by including a signature in the CertificateVerify
	message as described in Section 5.8.		message as described in Section 5.8.
	3.2. ECDSA_fixed_ECDH
	To use this authentication mechanism, the client MUST possess a
	certificate containing an ECDH-capable public key, and that
	certificate MUST be signed with ECDSA. Furthermore, the client's
	ECDH key MUST be on the same elliptic curve as the server's long-term
	(certified) ECDH key. This might limit use of this mechanism to
	closed environments. In situations where the client has an ECC key
	on a different curve, it would have to authenticate using either
	ECDSA_sign or a non-ECC mechanism (e.g., RSA). Using fixed ECDH for
	both servers and clients is computationally more efficient than
	mechanisms providing forward secrecy.
	When using this authentication mechanism, the client MUST send an
	empty ClientKeyExchange as described in Section 5.7 and MUST NOT send
	the CertificateVerify message. The ClientKeyExchange is empty since
	the client's ECDH public key required by the server to compute the
	premaster secret is available inside the client's certificate. The
	client's ability to arrive at the same premaster secret as the server
	(demonstrated by a successful exchange of Finished messages) proves
	possession of the private key corresponding to the certified public
	key, and the CertificateVerify message is unnecessary.
	3.3. RSA_fixed_ECDH
	This authentication mechanism is identical to ECDSA_fixed_ECDH except
	that the client's certificate MUST be signed with RSA.
	Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH
	client authentication mechanisms require the client's certificate to
	be signed with a particular signature scheme, this specification does
	not impose restrictions on signature schemes used elsewhere in the
	certificate chain. (Often such restrictions will be useful, and it
	is expected that this will be taken into account in certification
	authorities' signing practices. However, such restrictions are not
	strictly required in general: Even if it is beyond the capabilities
	of a server to completely validate a given chain, the server may be
	able to validate the clients certificate by relying on a trust anchor
	that appears as one of the intermediate certificates in the chain.)
	4. TLS Extensions for ECC		4. TLS Extensions for ECC
	Two new TLS extensions are defined in this specification: (i) the		Two new TLS extensions are defined in this specification: (i) the
	Supported Elliptic Curves Extension, and (ii) the Supported Point		Supported Elliptic Curves Extension, and (ii) the Supported Point
	Formats Extension. These allow negotiating the use of specific		Formats Extension. These allow negotiating the use of specific
	curves and point formats (e.g., compressed vs. uncompressed,		curves and point formats (e.g., compressed vs. uncompressed,
	respectively) during a handshake starting a new session. These		respectively) during a handshake starting a new session. These
	extensions are especially relevant for constrained clients that may		extensions are especially relevant for constrained clients that may
	only support a limited number of curves or point formats. They		only support a limited number of curves or point formats. They
	follow the general approach outlined in [RFC4366]; message details		follow the general approach outlined in [RFC4366]; message details
	skipping to change at page 14, line 22 ¶		skipping to change at page 12, line 24 ¶
	The Supported Point Formats Extension is included in a ServerHello		The Supported Point Formats Extension is included in a ServerHello
	message in response to a ClientHello message containing the Supported		message in response to a ClientHello message containing the Supported
	Point Formats Extension when negotiating an ECC cipher suite.		Point Formats Extension when negotiating an ECC cipher suite.
	Meaning of this extension:		Meaning of this extension:
	This extension allows a server to enumerate the point formats it can		This extension allows a server to enumerate the point formats it can
	parse (for the curve that will appear in its ServerKeyExchange		parse (for the curve that will appear in its ServerKeyExchange
	message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key		message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key
	exchange algorithm, or for the curve that is used in the server's		exchange algorithm.
	public key that will appear in its Certificate message when using the
	ECDH_ECDSA or ECDH_RSA key exchange algorithm).
	Structure of this extension:		Structure of this extension:
	The server's Supported Point Formats Extension has the same structure		The server's Supported Point Formats Extension has the same structure
	as the client's Supported Point Formats Extension (see		as the client's Supported Point Formats Extension (see
	Section 5.1.2). Items in elliptic_curve_list here are ordered		Section 5.1.2). Items in ec_point_format_list here are ordered
	according to the server's preference (favorite choice first). Note		according to the server's preference (favorite choice first). Note
	that the server may include items that were not found in the client's		that the server may include items that were not found in the client's
	list (e.g., the server may prefer to receive points in compressed		list (e.g., the server may prefer to receive points in compressed
	format even when a client cannot parse this format: the same client		format even when a client cannot parse this format: the same client
	may nevertheless be capable of outputting points in compressed		may nevertheless be capable of outputting points in compressed
	format).		format).
	Actions of the sender:		Actions of the sender:
	A server that selects an ECC cipher suite in response to a		A server that selects an ECC cipher suite in response to a
	skipping to change at page 15, line 29 ¶		skipping to change at page 13, line 29 ¶
	public keys MUST be encoded in certificates as described in		public keys MUST be encoded in certificates as described in
	Section 5.9.		Section 5.9.
	NOTE: The server's Certificate message is capable of carrying a chain		NOTE: The server's Certificate message is capable of carrying a chain
	of certificates. The restrictions mentioned in Table 3 apply only to		of certificates. The restrictions mentioned in Table 3 apply only to
	the server's certificate (first in the chain).		the server's certificate (first in the chain).
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
	| Algorithm | Server Certificate Type |		| Algorithm | Server Certificate Type |
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
	| ECDH_ECDSA | Certificate MUST contain an ECDH-capable public |
	| | key. It MUST be signed with ECDSA. |
	| ECDHE_ECDSA | Certificate MUST contain an ECDSA-capable public |		| ECDHE_ECDSA | Certificate MUST contain an ECDSA-capable public |
	| | key. It MUST be signed with ECDSA. |		| | key. It MUST be signed with ECDSA. |
	| ECDH_RSA | Certificate MUST contain an ECDH-capable public |
	| | key. It MUST be signed with RSA. |
	| ECDHE_RSA | Certificate MUST contain an RSA public key |		| ECDHE_RSA | Certificate MUST contain an RSA public key |
	| | authorized for use in digital signatures. It MUST |		| | authorized for use in digital signatures. It MUST |
	| | be signed with RSA. |		| | be signed with RSA. |
	+-------------+-----------------------------------------------------+		+-------------+-----------------------------------------------------+
	Table 3: Server Certificate Types		Table 3: Server Certificate Types
	Structure of this message:		Structure of this message:
	Identical to the TLS Certificate format.		Identical to the TLS Certificate format.
	skipping to change at page 17, line 25 ¶		skipping to change at page 15, line 25 ¶
	struct {		struct {
	opaque point <1..2^8-1>;		opaque point <1..2^8-1>;
	} ECPoint;		} ECPoint;
	point: This is the byte string representation of an elliptic curve		point: This is the byte string representation of an elliptic curve
	point following the conversion routine in Section 4.3.6 of		point following the conversion routine in Section 4.3.6 of
	[ANSI.X9-62.2005]. This byte string may represent an elliptic		[ANSI.X9-62.2005]. This byte string may represent an elliptic
	curve point in uncompressed or compressed format; it MUST conform		curve point in uncompressed or compressed format; it MUST conform
	to what the client has requested through a Supported Point Formats		to what the client has requested through a Supported Point Formats
	Extension if this extension was used.		Extension if this extension was used.
	enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;		enum {
			ec_basis_trinomial(1), ec_basis_pentanomial(2),
			(255)
			} ECBasisType;
	ec_basis_trinomial: Indicates representation of a characteristic-2		ec_basis_trinomial: Indicates representation of a characteristic-2
	field using a trinomial basis.		field using a trinomial basis.
	ec_basis_pentanomial: Indicates representation of a characteristic-2		ec_basis_pentanomial: Indicates representation of a characteristic-2
	field using a pentanomial basis.		field using a pentanomial basis.
	struct {		struct {
	ECCurveType curve_type;		ECCurveType curve_type;
	select (curve_type) {		select (curve_type) {
	case explicit_prime:		case explicit_prime:
	opaque prime_p <1..2^8-1>;		opaque prime_p <1..2^8-1>;
	ECCurve curve;		ECCurve curve;
	ECPoint base;		ECPoint base;
	opaque order <1..2^8-1>;		opaque order <1..2^8-1>;
	opaque cofactor <1..2^8-1>;		opaque cofactor <1..2^8-1>;
	case explicit_char2:		case explicit_char2:
	uint16 m;		uint16 m;
	ECBasisType basis;		ECBasisType basis;
	select (basis) {		select (basis) {
	case ec_trinomial:		case ec_basis_trinomial:
	opaque k <1..2^8-1>;		opaque k <1..2^8-1>;
	case ec_pentanomial:		case ec_basis_pentanomial:
	opaque k1 <1..2^8-1>;		opaque k1 <1..2^8-1>;
	opaque k2 <1..2^8-1>;		opaque k2 <1..2^8-1>;
	opaque k3 <1..2^8-1>;		opaque k3 <1..2^8-1>;
	};		};
	ECCurve curve;		ECCurve curve;
	ECPoint base;		ECPoint base;
	opaque order <1..2^8-1>;		opaque order <1..2^8-1>;
	opaque cofactor <1..2^8-1>;		opaque cofactor <1..2^8-1>;
	case named_curve:		case named_curve:
	NamedCurve namedcurve;		NamedCurve namedcurve;
	skipping to change at page 26, line 15 ¶		skipping to change at page 24, line 15 ¶
	[PKCS1] block type 1.		[PKCS1] block type 1.
	6. Cipher Suites		6. Cipher Suites
	The table below defines new ECC cipher suites that use the key		The table below defines new ECC cipher suites that use the key
	exchange algorithms specified in Section 2.		exchange algorithms specified in Section 2.
	+---------------------------------------+----------------+		+---------------------------------------+----------------+
	| CipherSuite | Identifier |		| CipherSuite | Identifier |
	+---------------------------------------+----------------+		+---------------------------------------+----------------+
	| TLS_ECDH_ECDSA_WITH_NULL_SHA | { 0xC0, 0x01 } |
	| TLS_ECDH_ECDSA_WITH_RC4_128_SHA | { 0xC0, 0x02 } |
	| TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x03 } |
	| TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x04 } |
	| TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x05 } |
	| | |
	| TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } |		| TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } |
	| TLS_ECDHE_ECDSA_WITH_RC4_128_SHA | { 0xC0, 0x07 } |		| TLS_ECDHE_ECDSA_WITH_RC4_128_SHA | { 0xC0, 0x07 } |
	| TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } |		| TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } |
	| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } |		| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } |
	| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } |		| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } |
	| | |		| | |
	| TLS_ECDH_RSA_WITH_NULL_SHA | { 0xC0, 0x0B } |
	| TLS_ECDH_RSA_WITH_RC4_128_SHA | { 0xC0, 0x0C } |
	| TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x0D } |
	| TLS_ECDH_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x0E } |
	| TLS_ECDH_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0F } |
	| | |
	| TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } |		| TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } |
	| TLS_ECDHE_RSA_WITH_RC4_128_SHA | { 0xC0, 0x11 } |		| TLS_ECDHE_RSA_WITH_RC4_128_SHA | { 0xC0, 0x11 } |
	| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } |		| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } |
	| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } |		| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } |
	| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } |		| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } |
	| | |		| | |
	| TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } |		| TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } |
	| TLS_ECDH_anon_WITH_RC4_128_SHA | { 0xC0, 0x16 } |		| TLS_ECDH_anon_WITH_RC4_128_SHA | { 0xC0, 0x16 } |
	| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } |		| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } |
	| TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } |		| TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } |
	skipping to change at page 27, line 9 ¶		skipping to change at page 24, line 45 ¶
	The key exchange method, cipher, and hash algorithm for each of these		The key exchange method, cipher, and hash algorithm for each of these
	cipher suites are easily determined by examining the name. Ciphers		cipher suites are easily determined by examining the name. Ciphers
	(other than AES ciphers) and hash algorithms are defined in [RFC2246]		(other than AES ciphers) and hash algorithms are defined in [RFC2246]
	and [RFC4346]. AES ciphers are defined in [RFC5246].		and [RFC4346]. AES ciphers are defined in [RFC5246].
	Server implementations SHOULD support all of the following cipher		Server implementations SHOULD support all of the following cipher
	suites, and client implementations SHOULD support at least one of		suites, and client implementations SHOULD support at least one of
	them:		them:
	o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA		o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA		o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
	o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA		o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
	o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.		o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
	7. Security Considerations		7. Security Considerations
	Security issues are discussed throughout this memo.		Security issues are discussed throughout this memo.
	For TLS handshakes using ECC cipher suites, the security		For TLS handshakes using ECC cipher suites, the security
	considerations in appendices D of all three TLS base documemts apply		considerations in appendices D of all three TLS base documemts apply
	accordingly.		accordingly.
	Security discussions specific to ECC can be found in		Security discussions specific to ECC can be found in
	skipping to change at page 28, line 5 ¶		skipping to change at page 25, line 43 ¶
	this document references [IEEE.P1363.1998], [ANSI.X9-62.2005].		this document references [IEEE.P1363.1998], [ANSI.X9-62.2005].
	Another issue is the potential for catastrophic failures when a		Another issue is the potential for catastrophic failures when a
	single elliptic curve is widely used. In this case, an attack on the		single elliptic curve is widely used. In this case, an attack on the
	elliptic curve might result in the compromise of a large number of		elliptic curve might result in the compromise of a large number of
	keys. Again, this concern may need to be balanced against efficiency		keys. Again, this concern may need to be balanced against efficiency
	and interoperability improvements associated with widely-used curves.		and interoperability improvements associated with widely-used curves.
	Substantial additional information on elliptic curve choice can be		Substantial additional information on elliptic curve choice can be
	found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4].		found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4].
	Implementers and users must also consider whether they need forward		All of the key exchange algorithms defined in this document provide
	secrecy. Forward secrecy refers to the property that session keys		forward secrecy. Some of the deprecated key exchange algorithms do
	are not compromised if the static, certified keys belonging to the		not.
	server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key
	exchange algorithms provide forward secrecy protection in the event
	of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
	Similarly, if the client is providing a static, certified key,
	ECDSA_sign client authentication provides forward secrecy protection
	in the event of client key compromise, while ECDSA_fixed_ECDH and
	RSA_fixed_ECDH do not. Thus, to obtain complete forward secrecy
	protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,
	with ECDSA_sign used for client authentication if necessary. Here
	again the security benefits of forward secrecy may need to be
	balanced against the improved efficiency offered by other options.
	8. IANA Considerations		8. IANA Considerations
	[RFC4492], the predecessor of this document has already defined the		[RFC4492], the predecessor of this document has already defined the
	IANA registries for the following:		IANA registries for the following:
	o NamedCurve Section 5.1		o NamedCurve Section 5.1
	o ECPointFormat Section 5.1		o ECPointFormat Section 5.1
	o ECCurveType Section 5.4		o ECCurveType Section 5.4
	skipping to change at page 28, line 52 ¶		skipping to change at page 26, line 30 ¶
	o Chris Hawk		o Chris Hawk
	o Bodo Moeller		o Bodo Moeller
	In the predecessor document, the authors acknowledged the		In the predecessor document, the authors acknowledged the
	contributions of Bill Anderson and Tim Dierks.		contributions of Bill Anderson and Tim Dierks.
	10. Version History for This Draft		10. Version History for This Draft
	NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION		NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION
			Changes from draft-nir-tls-rfc4492bis-00 and draft-ietf-tls-
			rfc4492bis-00 to draft-nir-tls-rfc4492bis-01:
			o Merged errata
			o Removed ECDH_RSA and ECDH_ECDSA
	Changes from RFC 4492 to draft-nir-tls-rfc4492bis-00:		Changes from RFC 4492 to draft-nir-tls-rfc4492bis-00:
	o Added TLS 1.2 to references.		o Added TLS 1.2 to references.
	o Moved RFC 4492 authors to acknowledgements.		o Moved RFC 4492 authors to acknowledgements.
	o Removed list of required reading for ECC.		o Removed list of required reading for ECC.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	skipping to change at page 31, line 42 ¶		skipping to change at page 29, line 42 ¶
	| secp256r1 | prime256v1 | NIST P-256 |		| secp256r1 | prime256v1 | NIST P-256 |
	| secp384r1 | | NIST P-384 |		| secp384r1 | | NIST P-384 |
	| secp521r1 | | NIST P-521 |		| secp521r1 | | NIST P-521 |
	+-----------+------------+------------+		+-----------+------------+------------+
	Table 6: Equivalent curves defined by SECG, ANSI, and NIST		Table 6: Equivalent curves defined by SECG, ANSI, and NIST
	Appendix B. Differences from RFC 4492		Appendix B. Differences from RFC 4492
	o Added TLS 1.2		o Added TLS 1.2
			o Merged Errata
			o Removed the ECDH key exchange algorithms: ECDH_RSA and ECDH_ECDSA
			o Deprecated a bunch of ciphersuites:
			TLS_ECDH_ECDSA_WITH_NULL_SHA
			TLS_ECDH_ECDSA_WITH_RC4_128_SHA
			TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
			TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
			TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
			TLS_ECDH_RSA_WITH_NULL_SHA
			TLS_ECDH_RSA_WITH_RC4_128_SHA
			TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
			TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
			TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
	Author's Address		Author's Address
	Yoav Nir		Yoav Nir
	Check Point Software Technologies Ltd.		Check Point Software Technologies Ltd.
	5 Hasolelim st.		5 Hasolelim st.
	Tel Aviv 6789735		Tel Aviv 6789735
	Israel		Israel
	Email: ynir.ietf@gmail.com		Email: ynir.ietf@gmail.com
End of changes. 31 change blocks.
	210 lines changed or deleted		115 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/