< draft-ietf-tls-ecc-05.txt   draft-ietf-tls-ecc-06.txt >
TLS Working Group V. Gupta TLS Working Group V. Gupta
Internet-Draft Sun Labs Internet-Draft Sun Labs
Expires: July 1, 2004 S. Blake-Wilson Expires: October 30, 2004 S. Blake-Wilson
BCI BCI
B. Moeller B. Moeller
University of California, Berkeley University of California, Berkeley
C. Hawk C. Hawk
Independent Consultant Independent Consultant
N. Bolyard N. Bolyard
Netscape Netscape
Jan. 2004 May. 2004
ECC Cipher Suites for TLS ECC Cipher Suites for TLS
<draft-ietf-tls-ecc-05.txt> <draft-ietf-tls-ecc-06.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 39 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 July 1, 2004. This Internet-Draft will expire on October 30, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 8
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. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11
5. Data Structures and Computations . . . . . . . . . . . . . . 12 5. Data Structures and Computations . . . . . . . . . . . . . . 12
5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . . 12 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . . 12
5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . . 15 5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . . 15
5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . . 15 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . . 16
5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 17 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 17
5.5 Certificate Request . . . . . . . . . . . . . . . . . . . . 21 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . . 21
5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . . 21 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . . 21
5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 23 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 23
5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . . 24 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . . 24
5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . . 25 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . . 25
5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . 25 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . 25
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 27 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . 29
8. Intellectual Property Rights . . . . . . . . . . . . . . . . 30 8. Intellectual Property Rights . . . . . . . . . . . . . . . . 30
skipping to change at page 5, line 37 skipping to change at page 5, line 37
ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
ECDH_RSA Fixed ECDH with RSA-signed certificates. ECDH_RSA Fixed ECDH with RSA-signed certificates.
ECDHE_RSA Ephemeral ECDH with RSA signatures. ECDHE_RSA Ephemeral ECDH with RSA signatures.
ECDH_anon Anonymous ECDH, no signatures. ECDH_anon Anonymous ECDH, no signatures.
Table 2: ECC key exchange algorithms Table 2: ECC key exchange algorithms
Note that the anonymous key exchange algorithm does not provide The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
authentication of the server or the client. Like other anonymous TLS secrecy. With ECDHE_RSA, a server can reuse its existing RSA
key exchanges, it is subject to man-in-the-middle attacks. certificate and easily comply with a constrained client's elliptic
Implementations of this algorithm SHOULD provide authentication by curve preferences (see Section 4). However, the computational cost
other means. incurred by a server is higher for ECDHE_RSA than for the traditional
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 trusted key
store in 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
of the server or the client. Like other anonymous TLS key exchanges,
it is subject to man-in-the-middle attacks. Implementations of this
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 X509.v3 keyUsage and keys. A certificate issuer may use X509.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
similarly. similarly.
Client Server Client Server
------ ------ ------ ------
skipping to change at page 10, line 11 skipping to change at page 10, line 11
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 5.8. 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. 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 either using
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 When using this authentication mechanism, the client MUST send an
empty ClientKeyExchange as described in Section 5.7 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.
skipping to change at page 12, line 33 skipping to change at page 12, line 33
Meaning of this message: Meaning of this message:
These extensions allow a constrained client to enumerate the elliptic These extensions allow a constrained client to enumerate the elliptic
curves and/or point formats it supports. curves and/or point formats it supports.
Structure of this message: Structure of this message:
The general structure of TLS extensions is described in [3] and this The general structure of TLS extensions is described in [3] and this
specification adds two new types to ExtensionType. specification adds two new types to ExtensionType.
enum { ellptic_curves(6), ec_point_formats(7) } ExtensionType; enum { elliptic_curves(6), ec_point_formats(7) } ExtensionType;
elliptic_curves: Indicates the set of elliptic curves supported by elliptic_curves: Indicates the set of elliptic curves supported by
the client. For this extension, the opaque extension_data field the client. For this extension, the opaque extension_data field
contains EllipticCurveList. contains EllipticCurveList.
ec_point_formats: Indicates the set of point formats supported by ec_point_formats: Indicates the set of point formats supported by
the client. For this extension, the opaque extension_data field the client. For this extension, the opaque extension_data field
contains ECPointFormatList. contains ECPointFormatList.
enum { enum {
skipping to change at page 13, line 25 skipping to change at page 13, line 25
arbitrary_explicit_prime_curves(253), arbitrary_explicit_prime_curves(253),
arbitrary_explicit_char2_curves(254), arbitrary_explicit_char2_curves(254),
(255) (255)
} NamedCurve; } NamedCurve;
sect163k1, etc: Indicates support of the corresponding named curve sect163k1, etc: Indicates support of the corresponding named curve
specified in SEC 2 [10]. Note that many of these curves are also 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 recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240
through 247 are reserved for private use. Values 253 and 254 through 247 are reserved for private use. Values 253 and 254
indicate that the client supports arbitrary prime and indicate that the client supports arbitrary prime and
charactersitic two curves, respectively (the curve parameters must characteristic-2 curves, respectively (the curve parameters must
be encoded explicitly in ECParameters). be encoded explicitly in ECParameters).
struct { struct {
NamedCurve elliptic_curve_list<1..2^16-1> NamedCurve elliptic_curve_list<1..2^8-1>
} EllipticCurveList; } EllipticCurveList;
Items in elliptic_curve_list are ordered according to the client's Items in elliptic_curve_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
As an example, a client that only supports secp192r1 (aka NIST P-192) As an example, a client that only supports secp192r1 (aka NIST P-192)
and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would
include an elliptic_curves extension with the following octets: include an elliptic_curves extension with the following octets:
00 06 00 02 13 15 00 06 02 13 15
A client that supports arbitrary explicit binary polynomial curves A client that supports arbitrary explicit binary polynomial curves
would include an extension with the following octets: would include an extension with the following octets:
00 06 00 01 fe 00 06 01 fe
enum { uncompressed (0), ansiX963_compressed (1), ansiX963_hybrid (2) } enum { uncompressed (0), ansiX963_compressed (1),
ECPointFormat; ansiX963_hybrid (2), (255)
} ECPointFormat;
struct { struct {
ECPointFormat ec_point_format_list<1..2^16-1> ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList; } ECPointFormatList;
Three point formats are included in the defintion of ECPointFormat
above. The uncompressed point format is the default format that
implementations of this document MUST support. The
ansix963_compressed format reduces bandwidth by including only the x-
coordinate and a single bit of the y-coordinate of the point. The
ansix963_hybrid format includes both the full y-coordinate and the
compressed y-coordinate to allow flexibility and improve efficiency
in some cases. Implementations of this document MAY support the
ansix963_compressed and ansix963_hybrid point formats.
Items in ec_point_format_list are ordered according to the client's Items in ec_point_format_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
A client that only supports the uncompressed point format includes an A client that only supports the uncompressed point format includes an
extension with the following octets: extension with the following octets:
00 07 00 01 00 00 07 01 00
A client that prefers the use of the ansiX963_compressed format over A client that prefers the use of the ansiX963_compressed format over
uncompressed may indicate that preference by including an extension uncompressed may indicate that preference by including an extension
with the following octets: with the following octets:
00 07 00 02 01 00 00 07 02 01 00
Actions of the sender: Actions of the sender:
A client that proposes ECC cipher suites in its ClientHello appends A client that proposes ECC cipher suites in its ClientHello appends
these extensions (along with any others) enumerating the curves and these extensions (along with any others) enumerating the curves and
point formats it supports. point formats it supports.
Actions of the receiver: Actions of the receiver:
A server that receives a ClientHello containing one or both of these A server that receives a ClientHello containing one or both of these
skipping to change at page 17, line 29 skipping to change at page 17, line 38
enum { explicit_prime (1), explicit_char2 (2), enum { explicit_prime (1), explicit_char2 (2),
named_curve (3), (255) } ECCurveType; named_curve (3), (255) } ECCurveType;
explicit_prime: Indicates the elliptic curve domain parameters are explicit_prime: Indicates the elliptic curve domain parameters are
conveyed verbosely, and the underlying finite field is a prime conveyed verbosely, and the underlying finite field is a prime
field. field.
explicit_char2: Indicates the elliptic curve domain parameters are explicit_char2: Indicates the elliptic curve domain parameters are
conveyed verbosely, and the underlying finite field is a conveyed verbosely, and the underlying finite field is a
characteristic 2 field. characteristic-2 field.
named_curve: Indicates that a named curve is used. This option named_curve: Indicates that a named curve is used. This option
SHOULD be used when applicable. SHOULD be used when applicable.
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>;
} ECCurve; } ECCurve;
a, b: These parameters specify the coefficients of the elliptic a, b: These parameters specify the coefficients of the elliptic
skipping to change at page 18, line 4 skipping to change at page 18, line 12
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 [6]. ANSI X9.62 [6].
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 [6]. 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.
of this specification MUST support the uncompressed form and MAY
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-2
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-2
two 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>;
skipping to change at page 19, line 15 skipping to change at page 19, line 20
curve: Specifies the coefficients a and b of the elliptic curve E. curve: Specifies the coefficients a and b of the elliptic curve E.
base: Specifies the base point G on the elliptic curve. base: Specifies the base point G on the elliptic curve.
order: Specifies the order n of the base point. order: Specifies the order n of the base point.
cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
represents the number of points on the elliptic curve E defined represents the number of points on the elliptic curve E defined
over the field Fq. over the field Fq.
m: This is the degree of the characteristic-two field F2^m. m: This is the degree of the characteristic-2 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. All enum values of NamedCurve are allowed except for parameters. All enum values of NamedCurve are allowed except for
arbitrary_explicit_prime_curves(253) and arbitrary_explicit_prime_curves(253) and
skipping to change at page 25, line 30 skipping to change at page 25, line 30
X509 certificates containing ECC public keys or signed using ECDSA X509 certificates containing ECC public keys or signed using ECDSA
MUST comply with [11] or another RFC that replaces or extends it. MUST comply with [11] or another RFC that replaces or extends it.
Clients SHOULD use the elliptic curve domain parameters recommended Clients SHOULD use the elliptic curve domain parameters recommended
in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10].
5.10 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 [5] as the shared secret calculation) MUST be performed according to [5]
using using the ECKAS-DH1 scheme with the identity map as key derivation
function, so that the premaster secret is the x-coordinate of the
o the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation ECDH shared secret elliptic curve point, i.e. the octet string Z in
primitive, the KDF1 key derivation function using SHA-1 [7], and IEEE 1363 terminology.
null key derivation parameters "P" for elliptic curve parameters
where field elements are represented as octet strings of length 24
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
SHA-1 output from the KDF.
o the ECKAS-DH1 scheme with the identity map as key derivation
function for elliptic curve parameters where field elements are
represented as octet strings of length more than 24; in this case,
the premaster secret is the x-coordinate of the ECDH shared secret
elliptic curve point, i.e. the octet string Z in IEEE 1363
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 [6] 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
skipping to change at page 27, line 10 skipping to change at page 27, line 10
with a public key in the parameters field of subjectPublicKeyInfo.) with a public key in the parameters field of subjectPublicKeyInfo.)
All RSA signatures must be generated and verified according to PKCS#1 All RSA signatures must be generated and verified according to PKCS#1
[9]. [9].
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.
EDITOR: Most of the cipher suites below have been left as ??. The CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? }
values 47-4C correspond to cipher suites which are known to have been CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
implemented and are therefore proposed here. The final determination CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? }
of cipher suite numbers will occur when this draft progresses to RFC. CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
Implementers using the values 47-4C should therefore be wary that CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
these values may change. CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 }
CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 }
CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 }
CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C }
CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? }
CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? }
skipping to change at page 29, line 10 skipping to change at page 29, line 10
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.
7. Security Considerations 7. Security Considerations
This document is based on [2], [5], [6] and [14]. 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 5.10), this document specifies two different ways One important issue that implementors and users must consider is
to compute the premaster secret. The choice of the method is elliptic curve selection. Guidance on selecting an appropriate
determined by the elliptic curve. Earlier versions of this elliptic curve size is given in Figure 1.
specification used the KDF1 key derivation function with SHA-1 in all
cases; the current version keeps this key derivation function only
for curves where field elements are represented as octet strings of
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 Beyond elliptic curve size, the main issue is elliptic curve
bits, independently of the elliptic curve used for ECDH. For large structure. As a general principle, it is more conservative to use
curves, this would result in worse security than expected. Using a elliptic curves with as little algebraic structure as possible - thus
specific key derivation function for ECDH is not really necessary as random curves are more conservative than special curves such as
TLS always uses its PRF to derive the master secret from the Koblitz curves, and curves over F_p with p random are more
premaster secret. For large curves, the current specification conservative than curves over F_p with p of a special form (and
handles ECDH like the basic TLS specification [14] handles standard curves over F_p with p random might be considered more conservative
DH. For smaller curves where the extra KDF1 step does not weaken than curves over F_2^m as there is no choice between multiple fields
security, the current specification keeps the KDF1 step to obtain of similar size for characteristic 2). Note, however, that algebraic
compatibility with existing implementations of earlier versions of structure can also lead to implementation efficiencies and
this specification. Note that the threshold for switching between implementors and users may, therefore, need to balance conservatism
the two ECDH calculation methods is necessarily somewhat arbitrary; against a need for efficiency. Concrete attacks are known against
192-bit ECC corresponds to approximately 96 bits of security in the only very few special classes of curves, such as supersingular
light of square root attacks, so the 160 bits provided by SHA-1 are curves, and these classes are excluded from the ECC standards that
comfortable at this limit. this document references [5], [6].
Another issue is the potential for catastrophic failures when a
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
keys. Again, this concern may need to be balanced against efficiency
and interoperability improvements associated with widely-used curves.
Substantial additional information on elliptic curve choice can be
found in [4], [5], [6], [8].
Implementors and users must also consider whether they need forward
secrecy. Forward secrecy refers to the property that session keys
are not compromised if the static, certified keys belonging to the
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. 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
 End of changes. 27 change blocks. 
83 lines changed or deleted 109 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/