< draft-ietf-tls-ecc-03.txt   draft-ietf-tls-ecc-04.txt >
TLS Working Group V. Gupta TLS Working Group V. Gupta
Internet-Draft Sun Labs Internet-Draft Sun Labs
Expires: December 2003 S. Blake-Wilson Expires: May 1, 2004 S. Blake-Wilson
BCI BCI
B. Moeller B. Moeller
Technische Universitaet Darmstadt TBD
C. Hawk C. Hawk
Independent Consultant Independent Consultant
June 2003 N. Bolyard
Netscape
Nov. 2003
ECC Cipher Suites for TLS ECC Cipher Suites for TLS
<draft-ietf-tls-ecc-03.txt> <draft-ietf-tls-ecc-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 39
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."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 30, 2003. This Internet-Draft will expire on May 1, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes new key exchange algorithms based on Elliptic This document describes new key exchange algorithms based on Elliptic
Curve Cryptography (ECC) for the TLS (Transport Layer Security) Curve Cryptography (ECC) for the TLS (Transport Layer Security)
protocol. In particular, it specifies the use of Elliptic Curve protocol. In particular, it specifies the use of Elliptic Curve
skipping to change at page 2, line 13 skipping to change at page 2, line 15
authentication mechanism. authentication mechanism.
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 [1]. document are to be interpreted as described in RFC 2119 [1].
Please send comments on this document to the TLS mailing list. Please send comments on this document to the TLS mailing list.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 5 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5
2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Client Authentication . . . . . . . . . . . . . . . . . . . . 9 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9
3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10
3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . 10
4. Data Structures and Computations . . . . . . . . . . . . . . . 11 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11
4.1 Server Certificate . . . . . . . . . . . . . . . . . . . . . . 11 5. Data Structures and Computations . . . . . . . . . . . . . . 12
4.2 Server Key Exchange . . . . . . . . . . . . . . . . . . . . . 12 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . . 12
4.3 Certificate Request . . . . . . . . . . . . . . . . . . . . . 17 5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . . 14
4.4 Client Certificate . . . . . . . . . . . . . . . . . . . . . . 18 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . . 15
4.5 Client Key Exchange . . . . . . . . . . . . . . . . . . . . . 19 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 16
4.6 Certificate Verify . . . . . . . . . . . . . . . . . . . . . . 20 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . . 20
4.7 Elliptic Curve Certificates . . . . . . . . . . . . . . . . . 22 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . . 21
4.8 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . . 22 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 22
5. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 23 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . . 25
7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 26 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . 25
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 27
References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 8. Intellectual Property Rights . . . . . . . . . . . . . . . . 30
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31
Normative References . . . . . . . . . . . . . . . . . . . . 32
Informative References . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33
Full Copyright Statement . . . . . . . . . . . . . . . . . . 35
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 for mobile/wireless environments. Compared public-key cryptosystem for mobile/wireless environments. Compared
to currently prevalent cryptosystems such as RSA, ECC offers to currently prevalent cryptosystems such as RSA, ECC offers
equivalent security with smaller key sizes. This is illustrated in equivalent security with smaller key sizes. This is illustrated in
the following table, based on [2], which gives approximate comparable the following table, based on [12], which gives approximate
key sizes for symmetric- and asymmetric-key cryptosystems based on comparable key sizes for symmetric- and asymmetric-key cryptosystems
the best-known algorithms for attacking them. based on the best-known algorithms for attacking them.
Symmetric | ECC | DH/DSA/RSA Symmetric | ECC | DH/DSA/RSA
-------------+---------+------------ -------------+---------+------------
80 | 163 | 1024 80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072 128 | 283 | 3072
192 | 409 | 7680 192 | 409 | 7680
256 | 571 | 15360 256 | 571 | 15360
Table 1: Comparable key sizes (in bits) Table 1: Comparable key sizes (in bits)
Smaller key sizes result in power, bandwidth and computational Smaller key sizes result in power, bandwidth and computational
savings that make ECC especially attractive for constrained savings that make ECC especially attractive for constrained
environments. environments.
skipping to change at page 3, line 41 skipping to change at page 3, line 42
o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
scheme with long-term or ephemeral keys to establish the TLS scheme with long-term or ephemeral keys to establish the TLS
premaster secret, and premaster secret, and
o the use of fixed-ECDH certificates and ECDSA for authentication of o the use of fixed-ECDH certificates and ECDSA for authentication of
TLS peers. 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. Section 4 specifies various data structures needed authentication. TLS extensions that allow a client to negotiate the
for an ECC-based handshake, their encoding in TLS messages and the use of specific curves and point formats are presented in Section 4.
processing of those messages. Section 5 defines new ECC-based cipher Section 5 specifies various data structures needed for an ECC-based
suites and identifies a small subset of these as recommended for all handshake, their encoding in TLS messages and the processing of those
implementations of this specification. Section 6, Section 7 and messages. Section 6 defines new ECC-based cipher suites and
Section 8 mention security considerations, intellectual property identifies a small subset of these as recommended for all
implementations of this specification. Section 7, Section 8 and
Section 9 mention security considerations, intellectual property
rights, and acknowledgments, respectively. This is followed by a rights, and acknowledgments, respectively. This is followed by a
list of references cited in this document and the authors' contact list of references cited in this document and the authors' contact
information. information.
Implementation of this specification requires familiarity with both Implementation of this specification requires familiarity with TLS
TLS [3] and ECC [5][6][7][9] . [2], TLS extensions [3] and ECC [4][5][6][8] .
2. Key Exchange Algorithms 2. Key Exchange Algorithms
This document introduces five new ECC-based key exchange algorithms This document introduces five new ECC-based key exchange algorithms
for TLS. All of them use ECDH to compute the TLS premaster secret for TLS. All of them use ECDH to compute the TLS premaster secret
and differ only in the lifetime of ECDH keys (long-term or ephemeral) and differ only in the lifetime of ECDH keys (long-term or ephemeral)
and the mechanism (if any) used to authenticate them. The derivation and the mechanism (if any) used to authenticate them. The derivation
of the TLS master secret from the premaster secret and the subsequent of the TLS master secret from the premaster secret and the subsequent
generation of bulk encryption/MAC keys and initialization vectors is generation of bulk encryption/MAC keys and initialization vectors is
independent of the key exchange algorithm and not impacted by the independent of the key exchange algorithm and not impacted by the
introduction of ECC. 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, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [3]), mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [2]),
respectively. respectively.
Key Key
Exchange Exchange
Algorithm Description Algorithm Description
--------- ----------- --------- -----------
ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 1: Message flow in a full TLS handshake Figure 1: Message flow in a full TLS handshake
* message is not sent under some conditions * message is not sent under some conditions
+ message is not sent unless the client is + message is not sent unless the client is
authenticated authenticated
Figure 1 shows all messages involved in the TLS key establishment Figure 1 shows all messages involved in the TLS key establishment
protocol (aka full handshake). The addition of ECC has direct impact protocol (aka full handshake). The addition of ECC has direct impact
only on the the server's Certificate message, the ServerKeyExchange, only on the ClientHello, the ServerHello, the server's Certificate
the ClientKeyExchange, the CertificateRequest, the client's message, the ServerKeyExchange, the ClientKeyExchange, the
Certificate message, and the CertificateVerify. Next, we describe CertificateRequest, the client's Certificate message, and the
each ECC key exchange algorithm in greater detail in terms of the CertificateVerify. Next, we describe each ECC key exchange algorithm
content and processing of these messages. For ease of exposition, we in greater detail in terms of the content and processing of these
defer discussion of client authentication and associated messages messages. For ease of exposition, we defer discussion of client
(identified with a + in Figure 1) until Section 3. authentication and associated messages (identified with a + in Figure
1) until Section 3 and of the optional ECC-specific extensions (which
impact the Hello messages) until Section 4.
2.1 ECDH_ECDSA 2.1 ECDH_ECDSA
In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
public key and be signed with ECDSA. public key and be signed with ECDSA.
A ServerKeyExchange MUST NOT be sent (the server's certificate A ServerKeyExchange MUST NOT be sent (the server's certificate
contains all the necessary keying information required by the client contains all the necessary keying information required by the client
to arrive at the premaster secret). to arrive at the premaster secret).
The client MUST generate an ECDH key pair on the same curve as the The client MUST generate an ECDH key pair on the same curve as the
server's long-term public key and send its public key in the server's long-term public key and send its public key in the
ClientKeyExchange message (except when using client authentication ClientKeyExchange message (except when using client authentication
algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
modifications from section Section 3.2 or Section 3.3 apply). modifications from section Section 3.2 or Section 3.3 apply).
Both client and server MUST perform an ECDH operation and use the Both client and server MUST 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 4.8 calculations are performed as specified in Section 5.10
2.2 ECDHE_ECDSA 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 MUST send its ephemeral ECDH public key and a The server MUST send its ephemeral ECDH public key and a
specification of the corresponding curve in the ServerKeyExchange specification of the corresponding curve in the ServerKeyExchange
message. These parameters MUST be signed with ECDSA using the message. These parameters MUST be signed with ECDSA using the
private key corresponding to the public key in the server's private key corresponding to the public key in the server's
Certificate. Certificate.
The client MUST generate an ECDH key pair on the same curve as the The client MUST generate an ECDH key pair on the same curve as the
server's ephemeral ECDH key and send its public key in the server's ephemeral ECDH key and send its public key in the
ClientKeyExchange message. ClientKeyExchange message.
Both client and server MUST perform an ECDH operation (Section 4.8) Both client and server MUST perform an ECDH operation (Section 5.10)
and use the resultant shared secret as the premaster secret. and use the resultant shared secret as the premaster secret.
2.3 ECDH_RSA 2.3 ECDH_RSA
This key exchange algorithm is the same as ECDH_ECDSA except the This key exchange algorithm is the same as ECDH_ECDSA except the
server's certificate MUST be signed with RSA rather than ECDSA. server's certificate MUST be signed with RSA rather than ECDSA.
2.4 ECDHE_RSA 2.4 ECDHE_RSA
This key exchange algorithm is the same as ECDHE_ECDSA except the This key exchange algorithm is the same as ECDHE_ECDSA except the
skipping to change at page 8, line 9 skipping to change at page 8, line 11
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 MUST generate an ECDH key pair on the same curve as the The client MUST generate an ECDH key pair on the same curve as the
server's ephemeral ECDH key and send its public key in the server's ephemeral ECDH key and send its public key in the
ClientKeyExchange message. ClientKeyExchange message.
Both client and server MUST perform an ECDH operation and use the Both client and server MUST 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 4.8 calculations are performed as specified in Section 5.10
3. Client Authentication 3. Client Authentication
This document defines three new client authentication mechanisms This document defines three new client authentication mechanisms
named after the type of client certificate involved: ECDSA_sign, named after the type of client certificate involved: ECDSA_sign,
ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is
usable with any of the non-anonymous ECC key exchange algorithms usable with any of the non-anonymous ECC key exchange algorithms
described in Section 2 as well as other non-anonymous (non-ECC) key described in Section 2 as well as other non-anonymous (non-ECC) key
exchange algorithms defined in TLS [3]. The ECDSA_fixed_ECDH and exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and
RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
use of a long-term ECDH client key would jeopardize the forward use of a long-term ECDH client key would jeopardize the forward
secrecy property of these algorithms. 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 one or more of these certificate types in its CertificateRequest
message. The server MUST NOT include any certificate types that are message. The server MUST NOT include any certificate types that are
prohibited for the negotiated key exchange algorithm. The client prohibited for the negotiated key exchange algorithm. The client
must check if it possesses a certificate appropriate for any of the must check if it possesses a certificate appropriate for any of the
skipping to change at page 9, line 34 skipping to change at page 9, line 34
authentication. 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 4.4) and prove possession of the Certificate message (as per Section 5.6) and prove possession of the
private key corresponding to the certified key. The process of private key corresponding to the certified key. The process of
determining an appropriate certificate and proving possession is determining an appropriate certificate and proving possession is
different for each authentication mechanism and described below. different for each authentication mechanism and described below.
NOTE: It is permissible for a server to request (and the client to NOTE: It is permissible for a server to request (and the client to
send) a client certificate of a different type than the server send) a client certificate of a different type than the server
certificate. certificate.
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 MUST prove possession of the private key corresponding to The client MUST prove possession of the private key corresponding to
the certified key by including a signature in the CertificateVerify the certified key by including a signature in the CertificateVerify
message as described in Section 4.6. message as described in Section 5.8.
3.2 ECDSA_fixed_ECDH 3.2 ECDSA_fixed_ECDH
To use this authentication mechanism, the client MUST possess a To use this authentication mechanism, the client MUST possess a
certificate containing an ECDH-capable public key and that certificate containing an ECDH-capable public key and that
certificate MUST be signed with ECDSA. Furthermore, the client's 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 ECDH key MUST be on the same elliptic curve as the server's long-term
(certified) ECDH key. (certified) ECDH key.
When using this authentication mechanism, the client MUST send an When using this authentication mechanism, the client MUST send an
empty ClientKeyExchange as described in Section 4.5 and MUST NOT send empty ClientKeyExchange as described in Section 5.7 and MUST NOT send
the CertificateVerify message. The ClientKeyExchange is empty since the CertificateVerify message. The ClientKeyExchange is empty since
the client's ECDH public key required by the server to compute the the client's ECDH public key required by the server to compute the
premaster secret is available inside the client's certificate. The premaster secret is available inside the client's certificate. The
client's ability to arrive at the same premaster secret as the server client's ability to arrive at the same premaster secret as the server
(demonstrated by a successful exchange of Finished messages) proves (demonstrated by a successful exchange of Finished messages) proves
possession of the private key corresponding to the certified public possession of the private key corresponding to the certified public
key and the CertificateVerify message is unnecessary. key and the CertificateVerify message is unnecessary.
3.3 RSA_fixed_ECDH 3.3 RSA_fixed_ECDH
This authentication mechanism is identical to ECDSA_fixed_ECDH except This authentication mechanism is identical to ECDSA_fixed_ECDH except
the client's certificate MUST be signed with RSA. the client's certificate MUST be signed with RSA.
4. Data Structures and Computations 4. TLS Extensions for ECC
Two new TLS extensions --- (i) the Supported Elliptic Curves
Extension, and (ii) the Supported Point Formats Extension --- allow a
client to negotiate the use of specific curves and point formats
(e.g. compressed v/s uncompressed), respectively. These extensions
are especially relevant for constrained clients that may only support
a limited number of curves or point formats. They follow the
general approach outlined in [3]. The client enumerates the curves
and point formats it supports by including the appropriate extensions
in its ClientHello message. By echoing that extension in its
ServerHello, the server agrees to restrict its key selection or
encoding to the choices specified by the client.
A TLS client that proposes ECC cipher suites in its ClientHello
message SHOULD include these extensions. Servers implementing ECC
cipher suites MUST support these extensions and negotiate the use of
an ECC cipher suite only if they can complete the handshake while
limiting themselves to the curves and compression techniques
enumerated by the client. This eliminates the possibility that a
negotiated ECC handshake will be subsequently aborted due to a
client's inability to deal with the server's EC key.
These extensions MUST NOT be included if the client does not propose
any ECC cipher suites. A client that proposes ECC cipher suites may
choose not to include these extension. In this case, the server is
free to choose any one of the elliptic curves or point formats listed
in Section 5. That section also describes the structure and
processing of these extensions in greater detail.
5. Data Structures and Computations
This section specifies the data structures and computations used by This section specifies the data structures and computations used by
ECC-based key mechanisms specified in Section 2 and Section 3. The ECC-based key mechanisms specified in Section 2, Section 3 and
presentation language used here is the same as that used in TLS [3]. Section 4. The presentation language used here is the same as that
Since this specification extends TLS, these descriptions should be used in TLS [2]. Since this specification extends TLS, these
merged with those in the TLS specification and any others that extend descriptions should be merged with those in the TLS specification and
TLS. This means that enum types may not specify all possible values any others that extend TLS. This means that enum types may not
and structures with multiple formats chosen with a select() clause specify all possible values and structures with multiple formats
may not indicate all possible cases. chosen with a select() clause may not indicate all possible cases.
4.1 Server Certificate 5.1 Client Hello Extensions
When this message is sent:
The ECC extensions SHOULD be sent along with any ClientHello message
that proposes ECC cipher suites.
Meaning of this message:
These extensions allow a constrained client to enumerate the elliptic
curves and/or point formats it supports.
Structure of this message:
The general structure of TLS extensions is described in [3] and this
specification adds two new types to ExtensionType.
enum { ellptic_curves(6), ec_point_formats(7) } ExtensionType;
elliptic_curves: Indicates the set of elliptic curves supported by
the client. For this extension, the opaque extension_data field
contains EllipticCurveList.
ec_point_formats: Indicates the set of point formats supported by
the client. For this extension, the opaque extension_data field
contains ECPointFormatList.
enum {
sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25), reserved (240..247),
arbitrary_explicit_prime_curves(253),
arbitrary_explicit_char2_curves(254),
(255)
} NamedCurve;
sect163k1, etc: Indicates support of the corresponding named curve
specified in SEC 2 [10]. Note that many of these curves are also
recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240
through 247 are reserved for private use. Values 253 and 254
indicate that the client supports arbitrary prime and
charactersitic two curves, respectively (the curve parameters must
be encoded explicitly in ECParameters).
struct {
NamedCurve elliptic_curve_list<1..2^16-1>
} EllipticCurveList;
As an example, a client that only supports secp192r1 (aka NIST P-192)
and secp192r1 (aka NIST P-224) would include an elliptic_curves
extension with the following octets:
00 06 00 02 13 14
A client that supports arbitrary explicit binary polynomial curves
would include an extension with the following octets:
00 06 00 01 fe
enum { uncompressed (0), ansiX963_compressed (1), ansiX963_hybrid (2) }
ECPointFormat;
struct {
ECPointFormat ec_point_format_list<1..2^16-1>
} ECPointFormatList;
A client that only supports the uncompressed point format includes an
extension with the following octets:
00 07 00 01 00
A client that prefers the use of the ansiX963_compressed format over
uncompressed may indicate that preference by including an extension
with the following octets:
00 07 00 02 01 00
Actions of the sender:
A client that proposes ECC cipher suites in its ClientHello appends
these extensions (along with any others) enumerating the curves and
point formats it supports.
Actions of the receiver:
A server that receives a ClientHello containing one or both of these
extensions MUST use the client's enumerated capabilities to guide its
selection of an appropriate cipher suite. One of the proposed ECC
cipher suites must be negotiated only if the server can successfully
complete the handshake while using the curves and point formats
supported by the client.
NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA key in its certificate, and (ii)
the ephemeral ECDH key in the ServerKeyExchange message. The server
must consider the "elliptic_curves" extension in selecting both of
these curves.
If a server does not understand the "elliptic_curves" extension or is
unable to complete the ECC handshake while restricting itself to the
enumerated curves, it MUST NOT negotiate the use of an ECC cipher
suite. Depending on what other cipher suites are proposed by the
client and supported by the server, this may result in a fatal
handshake failure alert due to the lack of common cipher suites.
5.2 Server Hello Extensions
When this message is sent:
The ServerHello ECC extensions are sent in response to a Client Hello
message containing ECC extensions when negotiating an ECC cipher
suite.
Meaning of this message:
These extensions indicate the server's agreement to use only the
elliptic curves and point formats supported by the client during the
ECC-based key exchange.
Structure of this message:
The ECC extensions echoed by the server are the same as those in the
ClientHello except the "extension_data" field is empty.
For example, a server indicates its acceptance of the client's
elliptic_curves extension by sending an extension with the following
octets:
00 06 00 00
Actions of the sender:
A server makes sure that it can complete a proposed ECC key exchange
mechanism by restricting itself to the curves/point formats supported
by the client before sending these extensions.
Actions of the receiver:
A client that receives a ServerHello with ECC extensions proceeds
with an ECC key exchange assured that it will be able to handle the
server's EC key(s).
5.3 Server Certificate
When this message is sent: When this message is sent:
This message is sent in all non-anonymous ECC-based key exchange This message is sent in all non-anonymous ECC-based key exchange
algorithms. algorithms.
Meaning of this message: Meaning of this message:
This message is used to authentically convey the server's static This message is used to authentically convey the server's static
public key to the client. The following table shows the server public key to the client. The following table shows the server
certificate type appropriate for each key exchange algorithm. ECC certificate type appropriate for each key exchange algorithm. ECC
public keys must be encoded in certificates as described in Section public keys must be encoded in certificates as described in Section
4.7. 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).
Key Exchange Algorithm Server Certificate Type Key Exchange Algorithm Server Certificate Type
---------------------- ----------------------- ---------------------- -----------------------
ECDH_ECDSA Certificate must contain an ECDH_ECDSA Certificate must contain an
ECDH-capable public key. It ECDH-capable public key. It
skipping to change at page 12, line 42 skipping to change at page 16, line 42
The server constructs an appropriate certificate chain and conveys it The server constructs an appropriate certificate chain and conveys it
to the client in the Certificate message. to the client in the Certificate message.
Actions of the receiver: Actions of the receiver:
The client validates the certificate chain, extracts the server's The client validates the certificate chain, extracts the server's
public key, and checks that the key type is appropriate for the public key, and checks that the key type is appropriate for the
negotiated key exchange algorithm. negotiated key exchange algorithm.
4.2 Server Key Exchange 5.4 Server Key Exchange
When this message is sent: When this message is sent:
This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
ECDH_anon key exchange algorithms. ECDH_anon key exchange algorithms.
Meaning of this message: Meaning of this message:
This message is used to convey the server's ephemeral ECDH public key This message is used to convey the server's ephemeral ECDH public key
(and the corresponding elliptic curve domain parameters) to the (and the corresponding elliptic curve domain parameters) to the
skipping to change at page 13, line 32 skipping to change at page 17, line 32
struct { struct {
opaque a <1..2^8-1>; opaque a <1..2^8-1>;
opaque b <1..2^8-1>; opaque b <1..2^8-1>;
opaque seed <0..2^8-1>; opaque seed <0..2^8-1>;
} ECCurve; } ECCurve;
a, b: These parameters specify the coefficients of the elliptic a, b: These parameters specify the coefficients of the elliptic
curve. Each value contains the byte string representation of a curve. Each value contains the byte string representation of a
field element following the conversion routine in Section 4.3.3 of field element following the conversion routine in Section 4.3.3 of
ANSI X9.62 [7]. ANSI X9.62 [6].
seed: This is an optional parameter used to derive the coefficients seed: This is an optional parameter used to derive the coefficients
of a randomly generated elliptic curve. of a randomly generated elliptic curve.
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 ANSI point following the conversion routine in Section 4.3.6 of ANSI
X9.62 [7]. Note that this byte string may represent an elliptic X9.62 [6]. Note that this byte string may represent an elliptic
curve point in compressed or uncompressed form. Implementations curve point in compressed or uncompressed form. Implementations
of this specification MUST support the uncompressed form and MAY of this specification MUST support the uncompressed form and MAY
support the compressed form. support the compressed form.
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
ec_basis_trinomial: Indicates representation of a characteristic two ec_basis_trinomial: Indicates representation of a characteristic two
field using a trinomial basis. field using a trinomial basis.
ec_basis_pentanomial: Indicates representation of a characteristic ec_basis_pentanomial: Indicates representation of a characteristic
two field using a pentanomial basis. two field using a pentanomial basis.
enum {
sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25), reserved (240..247), (255)
} NamedCurve;
sect163k1, etc: Indicates use of the corresponding named curve
specified in SEC 2 [12]. Note that many of these curves are also
recommended in ANSI X9.62 [7], and FIPS 186-2 [9]. Values 240
through 247 are reserved for private use.
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:
skipping to change at page 16, line 10 skipping to change at page 19, line 20
m: This is the degree of the characteristic-two field F2^m. m: This is the degree of the characteristic-two field F2^m.
k: The exponent k for the trinomial basis representation x^m + x^k k: The exponent k for the trinomial basis representation x^m + x^k
+1. +1.
k1, k2, k3: The exponents for the pentanomial representation x^m + k1, k2, k3: The exponents for the pentanomial representation x^m +
x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
namedcurve: Specifies a recommended set of elliptic curve domain namedcurve: Specifies a recommended set of elliptic curve domain
parameters. parameters. All enum values of NamedCurve are allowed except for
arbitrary_explicit_prime_curves(253) and
arbitrary_explicit_char2_curves(254). These two values are only
allowed in the ClientHello extension.
struct { struct {
ECParameters curve_params; ECParameters curve_params;
ECPoint public; ECPoint public;
} ServerECDHParams; } ServerECDHParams;
curve_params: Specifies the elliptic curve domain parameters curve_params: Specifies the elliptic curve domain parameters
associated with the ECDH public key. associated with the ECDH public key.
public: The ephemeral ECDH public key. public: The ephemeral ECDH public key.
skipping to change at page 17, line 4 skipping to change at page 20, line 11
params: Specifies the ECDH public key and associated domain params: Specifies the ECDH public key and associated domain
parameters. parameters.
signed_params: A hash of the params, with the signature appropriate signed_params: A hash of the params, with the signature appropriate
to that hash applied. The private key corresponding to the to that hash applied. The private key corresponding to the
certified public key in the server's Certificate message is used certified public key in the server's Certificate message is used
for signing. for signing.
enum { ecdsa } SignatureAlgorithm; enum { ecdsa } SignatureAlgorithm;
select (SignatureAlgorithm) { select (SignatureAlgorithm) {
case ecdsa: case ecdsa:
digitally-signed struct { digitally-signed struct {
opaque sha_hash[sha_size]; opaque sha_hash[sha_size];
}; };
} Signature; } Signature;
NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange
algorithm and 'anonymous' for ECDH_anon. These cases are defined in algorithm and 'anonymous' for ECDH_anon. These cases are defined in
TLS [3]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA TLS [2]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA
signatures are generated and verified as described in Section 4.8. signatures are generated and verified as described in Section 5.10.
As per ANSI X9.62, an ECDSA signature consists of a pair of integers As per ANSI X9.62, an ECDSA signature consists of a pair of integers
r and s. These integers are both converted into byte strings of the r and s. These integers are both converted into byte strings of the
same length as the curve order n using the conversion routine same length as the curve order n using the conversion routine
specified in Section 4.3.1 of [7]. The two byte strings are specified in Section 4.3.1 of [6]. The two byte strings are
concatenated, and the result is placed in the signature field. concatenated, and the result is placed in the signature field.
Actions of the sender: Actions of the sender:
The server selects elliptic curve domain parameters and an ephemeral The server selects elliptic curve domain parameters and an ephemeral
ECDH public key corresponding to these parameters according to the ECDH public key corresponding to these parameters according to the
ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to
the client in the ServerKeyExchange message using the format defined the client in the ServerKeyExchange message using the format defined
above. above.
Actions of the recipient: Actions of the recipient:
The client verifies the signature (when present) and retrieves the The client verifies the signature (when present) and retrieves the
server's elliptic curve domain parameters and ephemeral ECDH public server's elliptic curve domain parameters and ephemeral ECDH public
key from the ServerKeyExchange message. key from the ServerKeyExchange message.
4.3 Certificate Request 5.5 Certificate Request
When this message is sent: When this message is sent:
This message is sent when requesting client authentication. This message is sent when requesting client authentication.
Meaning of this message: Meaning of this message:
The server uses this message to suggest acceptable client The server uses this message to suggest acceptable client
authentication methods. authentication methods.
skipping to change at page 18, line 17 skipping to change at page 21, line 24
ecdsa_fixed_ecdh(?), (255) ecdsa_fixed_ecdh(?), (255)
} ClientCertificateType; } ClientCertificateType;
ecdsa_sign, etc Indicates that the server would like to use the ecdsa_sign, etc Indicates that the server would like to use the
corresponding client authentication method specified in Section 3. corresponding client authentication method specified in Section 3.
EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
ecdsa_fixed_ecdh have been left as ?. These values will be ecdsa_fixed_ecdh have been left as ?. These values will be
assigned when this draft progresses to RFC. Earlier versions of assigned when this draft progresses to RFC. Earlier versions of
this draft used the values 5, 6, and 7 - however these values have this draft used the values 5, 6, and 7 - however these values have
been removed since they are used differently by SSL 3.0 and their been removed since they are used differently by SSL 3.0 [13] and
use by TLS is being deprecated. their use by TLS is being deprecated.
Actions of the sender: Actions of the sender:
The server decides which client authentication methods it would like The server decides which client authentication methods it would like
to use, and conveys this information to the client using the format to use, and conveys this information to the client using the format
defined above. defined above.
Actions of the receiver: Actions of the receiver:
The client determines whether it has an appropriate certificate for The client determines whether it has an appropriate certificate for
use with any of the requested methods, and decides whether or not to use with any of the requested methods, and decides whether or not to
proceed with client authentication. proceed with client authentication.
4.4 Client Certificate 5.6 Client Certificate
When this message is sent: When this message is sent:
This message is sent in response to a CertificateRequest when a This message is sent in response to a CertificateRequest when a
client has a suitable certificate. client has a suitable certificate.
Meaning of this message: Meaning of this message:
This message is used to authentically convey the client's static This message is used to authentically convey the client's static
public key to the server. The following table summarizes what client public key to the server. The following table summarizes what client
certificate types are appropriate for the ECC-based client certificate types are appropriate for the ECC-based client
authentication mechanisms described in Section 3. ECC public keys authentication mechanisms described in Section 3. ECC public keys
must be encoded in certificates as described in Section 4.7. must be encoded in certificates as described in Section 5.9.
NOTE: The client's Certificate message is capable of carrying a chain NOTE: The client's Certificate message is capable of carrying a chain
of certificates. The restrictions mentioned in Table 4 apply only to of certificates. The restrictions mentioned in Table 4 apply only to
the client's certificate (first in the chain). the client's certificate (first in the chain).
Client Client
Authentication Method Client Certificate Type Authentication Method Client Certificate Type
--------------------- ----------------------- --------------------- -----------------------
ECDSA_sign Certificate must contain an ECDSA_sign Certificate must contain an
skipping to change at page 19, line 42 skipping to change at page 22, line 46
The client constructs an appropriate certificate chain, and conveys The client constructs an appropriate certificate chain, and conveys
it to the server in the Certificate message. it to the server in the Certificate message.
Actions of the receiver: Actions of the receiver:
The TLS server validates the certificate chain, extracts the client's The TLS server validates the certificate chain, extracts the client's
public key, and checks that the key type is appropriate for the public key, and checks that the key type is appropriate for the
client authentication method. client authentication method.
4.5 Client Key Exchange 5.7 Client Key Exchange
When this message is sent: When this message is sent:
This message is sent in all key exchange algorithms. If client This message is sent in all key exchange algorithms. If client
authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
message is empty. Otherwise, it contains the client's ephemeral ECDH message is empty. Otherwise, it contains the client's ephemeral ECDH
public key. public key.
Meaning of the message: Meaning of the message:
skipping to change at page 20, line 39 skipping to change at page 23, line 44
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic; case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
Actions of the sender: Actions of the sender:
The client selects an ephemeral ECDH public key corresponding to the The client selects an ephemeral ECDH public key corresponding to the
parameters it received from the server according to the ECKAS-DH1 parameters it received from the server according to the ECKAS-DH1
scheme from IEEE 1363 [6]. It conveys this information to the client scheme from IEEE 1363 [5]. It conveys this information to the client
in the ClientKeyExchange message using the format defined above. in the ClientKeyExchange message using the format defined above.
Actions of the recipient: Actions of the recipient:
The server retrieves the client's ephemeral ECDH public key from the The server retrieves the client's ephemeral ECDH public key from the
ClientKeyExchange message and checks that it is on the same elliptic ClientKeyExchange message and checks that it is on the same elliptic
curve as the server's ECDH key. curve as the server's ECDH key.
4.6 Certificate Verify 5.8 Certificate Verify
When this message is sent: When this message is sent:
This message is sent when the client sends a client certificate This message is sent when the client sends a client certificate
containing a public key usable for digital signatures, e.g. when the containing a public key usable for digital signatures, e.g. when the
client is authenticated using the ECDSA_sign mechanism. client is authenticated using the ECDSA_sign mechanism.
Meaning of the message: Meaning of the message:
This message contains a signature that proves possession of the This message contains a signature that proves possession of the
skipping to change at page 21, line 31 skipping to change at page 24, line 37
select (SignatureAlgorithm) { select (SignatureAlgorithm) {
case ecdsa: case ecdsa:
digitally-signed struct { digitally-signed struct {
opaque sha_hash[sha_size]; opaque sha_hash[sha_size];
}; };
} Signature; } Signature;
For the ecdsa case, the signature field in the CertificateVerify For the ecdsa case, the signature field in the CertificateVerify
message contains an ECDSA signature computed over handshake messages message contains an ECDSA signature computed over handshake messages
exchanged so far. ECDSA signatures are computed as described in exchanged so far. ECDSA signatures are computed as described in
Section 4.8. As per ANSI X9.62, an ECDSA signature consists of a Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a
pair of integers r and s. These integers are both converted into pair of integers r and s. These integers are both converted into
byte strings of the same length as the curve order n using the byte strings of the same length as the curve order n using the
conversion routine specified in Section 4.3.1 of [7]. The two byte conversion routine specified in Section 4.3.1 of [6]. The two byte
strings are concatenated, and the result is placed in the signature strings are concatenated, and the result is placed in the signature
field. field.
Actions of the sender: Actions of the sender:
The client computes its signature over all handshake messages sent or The client computes its signature over all handshake messages sent or
received starting at client hello up to but not including this received starting at client hello up to but not including this
message. It uses the private key corresponding to its certified message. It uses the private key corresponding to its certified
public key to compute the signature which is conveyed in the format public key to compute the signature which is conveyed in the format
defined above. defined above.
Actions of the receiver: Actions of the receiver:
The server extracts the client's signature from the CertificateVerify The server extracts the client's signature from the CertificateVerify
message, and verifies the signature using the public key it received message, and verifies the signature using the public key it received
in the client's Certificate message. in the client's Certificate message.
4.7 Elliptic Curve Certificates 5.9 Elliptic Curve Certificates
X509 certificates containing ECC public keys or signed using ECDSA X509 certificates containing ECC public keys or signed using ECDSA
MUST comply with [14]. Clients SHOULD use the elliptic curve domain MUST comply with [11]. Clients SHOULD use the elliptic curve domain
parameters recommended in ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2 parameters recommended in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2
[12]. [10].
4.8 ECDH, ECDSA and RSA Computations 5.10 ECDH, ECDSA and RSA Computations
All ECDH calculations (including parameter and key generation as well All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) MUST be performed according to [6] as the shared secret calculation) MUST be performed according to [5]
using using
o the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation o the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation
primitive, the KDF1 key derivation function using SHA-1 [8], and primitive, the KDF1 key derivation function using SHA-1 [7], and
null key derivation parameters "P" for elliptic curve parameters null key derivation parameters "P" for elliptic curve parameters
where field elements are represented as octet strings of length 24 where field elements are represented as octet strings of length 24
or less (using the IEEE 1363 FE2OSP); in this case, the premaster or less (using the IEEE 1363 FE2OSP); in this case, the premaster
secret is the output of the ECKAS-DH1 scheme, i.e. the 20-byte secret is the output of the ECKAS-DH1 scheme, i.e. the 20-byte
SHA-1 output from the KDF. SHA-1 output from the KDF.
o the ECKAS-DH1 scheme with the identity map as key derivation o the ECKAS-DH1 scheme with the identity map as key derivation
function for elliptic curve parameters where field elements are function for elliptic curve parameters where field elements are
represented as octet strings of length more than 24; in this case, represented as octet strings of length more than 24; in this case,
the premaster secret is the x-coordinate of the ECDH shared secret the premaster secret is the x-coordinate of the ECDH shared secret
elliptic curve point, i.e. the octet string Z in IEEE 1363 elliptic curve point, i.e. the octet string Z in IEEE 1363
terminology. terminology.
Note that a new extension may be introduced in the future to allow Note that a new extension may be introduced in the future to allow
the use of a different KDF during computation of the premaster the use of a different KDF during computation of the premaster
secret. In this event, the new KDF would be used in place of the secret. In this event, the new KDF would be used in place of the
process detailed above. This may be desirable, for example, to process detailed above. This may be desirable, for example, to
support compatibility with the planned NIST key agreement standard. support compatibility with the planned NIST key agreement standard.
All ECDSA computations MUST be performed according to ANSI X9.62 [7] All ECDSA computations MUST be performed according to ANSI X9.62 [6]
or its successors. Data to be signed/verified is hashed and the or its successors. Data to be signed/verified is hashed and the
result run directly through the ECDSA algorithm with no additional result run directly through the ECDSA algorithm with no additional
hashing. The default hash function is SHA-1 [8] and sha_size (see hashing. The default hash function is SHA-1 [7] and sha_size (see
Section 4.2 and Section 4.6) is 20. However, an alternative hash Section 5.4 and Section 5.8) is 20. However, an alternative hash
function, such as one of the new SHA hash functions specified in FIPS function, such as one of the new SHA hash functions specified in FIPS
180-2 [8], may be used instead if the certificate containing the EC 180-2 [7], may be used instead if the certificate containing the EC
public key explicitly requires use of another hash function. public key explicitly requires use of another hash function.
All RSA signatures must be generated and verified according to PKCS#1 All RSA signatures must be generated and verified according to PKCS#1
[10]. [9].
5. 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.
EDITOR: Most of the cipher suites below have been left as ??. The EDITOR: Most of the cipher suites below have been left as ??. The
values 47-4C correspond to cipher suites which are known to have been values 47-4C correspond to cipher suites which are known to have been
implemented and are therefore proposed here. The final determination implemented and are therefore proposed here. The final determination
of cipher suite numbers will occur when this draft progresses to RFC. of cipher suite numbers will occur when this draft progresses to RFC.
Implementers using the values 47-4C should therefore be wary that Implementers using the values 47-4C should therefore be wary that
these values may change. these values may change.
skipping to change at page 24, line 4 skipping to change at page 28, line 4
CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
Table 5: TLS ECC cipher suites Table 5: TLS ECC cipher suites
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 [3]. AES other than AES ciphers, and hash algorithms are defined in [2]. AES
ciphers are defined in [11]. ciphers are defined in [14].
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: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
6. Security Considerations 7. Security Considerations
This document is based on [3], [6], [7] and [11]. The appropriate This document is based on [2], [5], [6] and [14]. The appropriate
security considerations of those documents apply. security considerations of those documents apply.
For ECDH (Section 4.8), this document specifies two different ways to For ECDH (Section 5.10), this document specifies two different ways
compute the premaster secret. The choice of the method is determined to compute the premaster secret. The choice of the method is
by the elliptic curve. Earlier versions of this specification used determined by the elliptic curve. Earlier versions of this
the KDF1 key derivation function with SHA-1 in all cases; the current specification used the KDF1 key derivation function with SHA-1 in all
version keeps this key derivation function only for curves where cases; the current version keeps this key derivation function only
field elements are represented as octet strings of length 24 or less for curves where field elements are represented as octet strings of
(i.e. up to 192 bits), but omits it for larger curves. length 24 or less (i.e. up to 192 bits), but omits it for larger
curves.
Rationale: Using KDF1 with SHA-1 limits the security to at most 160 Rationale: Using KDF1 with SHA-1 limits the security to at most 160
bits, independently of the elliptic curve used for ECDH. For large bits, independently of the elliptic curve used for ECDH. For large
curves, this would result in worse security than expected. Using a curves, this would result in worse security than expected. Using a
specific key derivation function for ECDH is not really necessary as specific key derivation function for ECDH is not really necessary as
TLS always uses its PRF to derive the master secret from the TLS always uses its PRF to derive the master secret from the
premaster secret. For large curves, the current specification premaster secret. For large curves, the current specification
handles ECDH like the basic TLS specification [11] handles standard handles ECDH like the basic TLS specification [14] handles standard
DH. For smaller curves where the extra KDF1 step does not weaken DH. For smaller curves where the extra KDF1 step does not weaken
security, the current specification keeps the KDF1 step to obtain security, the current specification keeps the KDF1 step to obtain
compatibility with existing implementations of earlier versions of compatibility with existing implementations of earlier versions of
this specification. Note that the threshold for switching between this specification. Note that the threshold for switching between
the two ECDH calculation methods is necessarily somewhat arbitrary; the two ECDH calculation methods is necessarily somewhat arbitrary;
192-bit ECC corresponds to approximately 96 bits of security in the 192-bit ECC corresponds to approximately 96 bits of security in the
light of square root attacks, so the 160 bits provided by SHA-1 are light of square root attacks, so the 160 bits provided by SHA-1 are
comfortable at this limit. comfortable at this limit.
7. Intellectual Property Rights 8. Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to the specification contained in this document. For more regard to the specification contained in this document. For more
information, consult the online list of claimed rights (http:// information, consult the online list of claimed rights (http://
www.ietf.org/ipr.html). www.ietf.org/ipr.html).
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in [13]. Copies of standards-related documentation can be found in [15]. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
8. Acknowledgments 9. Acknowledgments
The authors wish to thank Bill Anderson and Tim Dierks. The authors wish to thank Bill Anderson and Tim Dierks.
References Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[2] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
Sizes", Journal of Cryptology 14 (2001) 255-293, <http://
www.cryptosavvy.com/>.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999. 2246, January 1999.
[4] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
Version 3.0", November 1996, <http://wp.netscape.com/eng/ssl3/ T. Wright, "Transport Layer Security (TLS) Extensions", RFC
draft302.txt>. 3546, June 2003.
[5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http:// [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://
www.secg.org/>. www.secg.org/>.
[6] IEEE, "Standard Specifications for Public Key Cryptography", [5] IEEE, "Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000. IEEE 1363, 2000.
[7] ANSI, "Public Key Cryptography For The Financial Services [6] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998. (ECDSA)", ANSI X9.62, 1998.
[8] NIST, "Secure Hash Standard", FIPS 180-2, 2002. [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
[9] NIST, "Digital Signature Standard", FIPS 186-2, 2000. [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[10] RSA Laboratories, "PKCS#1: RSA Encryption Standard version [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
1.5", PKCS 1, November 1993. 1.5", PKCS 1, November 1993.
[11] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
Transport Layer Security (TLS)", RFC 3268, June 2002.
[12] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
2000, <http://www.secg.org/>. 2000, <http://www.secg.org/>.
[13] Hovey, R. and S. Bradner, "The Organizations Involved in the [11] Polk, T., Housley, R. and L. Bassham, "Algorithms and
IETF Standards Process", RFC 2028, BCP 11, October 1996.
[14] Polk, T., Housley, R. and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC Certificate and Certificate Revocation List (CRL) Profile", RFC
3279, April 2002. 3279, April 2002.
Informative References
[12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293, <http://
www.cryptosavvy.com/>.
[13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol
Version 3.0", November 1996, <http://wp.netscape.com/eng/ssl3/
draft302.txt>.
[14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[15] Hovey, R. and S. Bradner, "The Organizations Involved in the
IETF Standards Process", RFC 2028, BCP 11, October 1996.
Authors' Addresses Authors' Addresses
Vipul Gupta Vipul Gupta
Sun Microsystems Laboratories Sun Microsystems Laboratories
2600 Casey Avenue 2600 Casey Avenue
MS UMTV29-235 MS UMTV29-235
Mountain View, CA 94303 Mountain View, CA 94303
USA USA
Phone: +1 650 336 1681 Phone: +1 650 336 1681
skipping to change at page 29, line 28 skipping to change at page 33, line 44
Basic Commerce & Industries, Inc. Basic Commerce & Industries, Inc.
96 Spandia Ave 96 Spandia Ave
Unit 606 Unit 606
Toronto, ON M6G 2T6 Toronto, ON M6G 2T6
Canada Canada
Phone: +1 416 214 5961 Phone: +1 416 214 5961
EMail: sblakewilson@bcisse.com EMail: sblakewilson@bcisse.com
Bodo Moeller Bodo Moeller
Technische Universitaet Darmstadt TBD
Alexanderstr. 10
64283 Darmstadt
Germany
Phone: +49 6151 16 6628
EMail: moeller@cdc.informatik.tu-darmstadt.de EMail: moeller@cdc.informatik.tu-darmstadt.de
Chris Hawk Chris Hawk
Independent Consultant Independent Consultant
EMail: chris@socialeng.com EMail: chris@socialeng.com
Nelson Bolyard
Netscape
EMail: misterssl@aol.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
 End of changes. 75 change blocks. 
160 lines changed or deleted 343 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/