idnits 2.17.00 (12 Aug 2021) /tmp/idnits9822/draft-ietf-tls-ecc-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1276. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 705 has weird spacing: '...rveType cur...' == Line 718 has weird spacing: '... opaque k <1....' == Line 720 has weird spacing: '... opaque k1 <1...' == Line 721 has weird spacing: '... opaque k2 <1...' == Line 722 has weird spacing: '... opaque k3 <1...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 222 == Unused Reference: '15' is defined on line 1212, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) == Outdated reference: draft-ietf-tls-rfc3546bis has been published as RFC 4366 -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Obsolete informational reference (is this intentional?): RFC 3268 (ref. '14') (Obsoleted by RFC 5246) Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group V. Gupta 3 Internet-Draft Sun Labs 4 Expires: June 1, 2005 S. Blake-Wilson 5 BCI 6 B. Moeller 7 University of California, Berkeley 8 C. Hawk 9 Corriente Networks 10 N. Bolyard 11 Dec. 2004 13 ECC Cipher Suites for TLS 14 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all provisions 19 of section 3 of RFC 3667. By submitting this Internet-Draft, each 20 author represents that any applicable patent or other IPR claims of 21 which he or she is aware have been or will be disclosed, and any of 22 which he or she become aware will be disclosed, in accordance with 23 RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on June 1, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2004). 47 Abstract 49 This document describes new key exchange algorithms based on Elliptic 50 Curve Cryptography (ECC) for the TLS (Transport Layer Security) 51 protocol. In particular, it specifies the use of Elliptic Curve 52 Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of 53 Elliptic Curve Digital Signature Algorithm (ECDSA) as a new 54 authentication mechanism. 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [1]. 60 Please send comments on this document to the TLS mailing list. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5 66 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9 72 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 74 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 75 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 76 5. Data Structures and Computations . . . . . . . . . . . . . . 12 77 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 78 5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . 15 79 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16 80 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 17 81 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 20 82 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 21 83 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 22 84 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 23 85 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 25 86 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 25 87 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 26 88 7. Security Considerations . . . . . . . . . . . . . . . . . . 28 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 91 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 30 92 9.2 Informative References . . . . . . . . . . . . . . . . . . . 30 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 94 Intellectual Property and Copyright Statements . . . . . . . 33 96 1. Introduction 98 Elliptic Curve Cryptography (ECC) is emerging as an attractive 99 public-key cryptosystem for mobile/wireless environments. Compared 100 to currently prevalent cryptosystems such as RSA, ECC offers 101 equivalent security with smaller key sizes. This is illustrated in 102 the following table, based on [12], which gives approximate 103 comparable key sizes for symmetric- and asymmetric-key cryptosystems 104 based on the best-known algorithms for attacking them. 106 Symmetric | ECC | DH/DSA/RSA 107 -------------+---------+------------ 108 80 | 163 | 1024 109 112 | 233 | 2048 110 128 | 283 | 3072 111 192 | 409 | 7680 112 256 | 571 | 15360 114 Table 1: Comparable key sizes (in bits) 116 Figure 1 118 Smaller key sizes result in power, bandwidth and computational 119 savings that make ECC especially attractive for constrained 120 environments. 122 This document describes additions to TLS to support ECC. In 123 particular, it defines 124 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement 125 scheme with long-term or ephemeral keys to establish the TLS 126 premaster secret, and 127 o the use of fixed-ECDH certificates and ECDSA for authentication of 128 TLS peers. 130 The remainder of this document is organized as follows. Section 2 131 provides an overview of ECC-based key exchange algorithms for TLS. 132 Section 3 describes the use of ECC certificates for client 133 authentication. TLS extensions that allow a client to negotiate the 134 use of specific curves and point formats are presented in Section 4. 135 Section 5 specifies various data structures needed for an ECC-based 136 handshake, their encoding in TLS messages and the processing of those 137 messages. Section 6 defines new ECC-based cipher suites and 138 identifies a small subset of these as recommended for all 139 implementations of this specification. Section 7 and Section 8 140 mention security considerations and acknowledgments, respectively. 141 This is followed by a list of references cited in this document, the 142 authors' contact information, and statements on intellectual property 143 rights and copyrights. 145 Implementation of this specification requires familiarity with TLS 146 [2], TLS extensions [3] and ECC [4][5][6][8] . 148 2. Key Exchange Algorithms 150 This document introduces five new ECC-based key exchange algorithms 151 for TLS. All of them use ECDH to compute the TLS premaster secret 152 and differ only in the lifetime of ECDH keys (long-term or ephemeral) 153 and the mechanism (if any) used to authenticate them. The derivation 154 of the TLS master secret from the premaster secret and the subsequent 155 generation of bulk encryption/MAC keys and initialization vectors is 156 independent of the key exchange algorithm and not impacted by the 157 introduction of ECC. 159 The table below summarizes the new key exchange algorithms which 160 mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [2]), 161 respectively. 163 Key 164 Exchange 165 Algorithm Description 166 --------- ----------- 168 ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. 170 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. 172 ECDH_RSA Fixed ECDH with RSA-signed certificates. 174 ECDHE_RSA Ephemeral ECDH with RSA signatures. 176 ECDH_anon Anonymous ECDH, no signatures. 178 Table 2: ECC key exchange algorithms 180 Figure 2 182 The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward 183 secrecy. With ECDHE_RSA, a server can reuse its existing RSA 184 certificate and easily comply with a constrained client's elliptic 185 curve preferences (see Section 4). However, the computational cost 186 incurred by a server is higher for ECDHE_RSA than for the traditional 187 RSA key exchange which does not provide forward secrecy. 189 The ECDH_RSA mechanism requires a server to acquire an ECC 190 certificate but the certificate issuer can still use an existing RSA 191 key for signing. This eliminates the need to update the trusted key 192 store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for 193 the server as well as the certification authority and is best suited 194 for constrained devices unable to support RSA. 196 The anonymous key exchange algorithm does not provide authentication 197 of the server or the client. Like other anonymous TLS key exchanges, 198 it is subject to man-in-the-middle attacks. Implementations of this 199 algorithm SHOULD provide authentication by other means. 201 Note that there is no structural difference between ECDH and ECDSA 202 keys. A certificate issuer may use X509.v3 keyUsage and 203 extendedKeyUsage extensions to restrict the use of an ECC public key 204 to certain computations. This document refers to an ECC key as 205 ECDH-capable if its use in ECDH is permitted. ECDSA-capable is 206 defined similarly. 208 Client Server 209 ------ ------ 211 ClientHello --------> 212 ServerHello 213 Certificate* 214 ServerKeyExchange* 215 CertificateRequest*+ 216 <-------- ServerHelloDone 217 Certificate*+ 218 ClientKeyExchange 219 CertificateVerify*+ 220 [ChangeCipherSpec] 221 Finished --------> 222 [ChangeCipherSpec] 223 <-------- Finished 225 Application Data <-------> Application Data 227 Figure 1: Message flow in a full TLS handshake 228 * message is not sent under some conditions 229 + message is not sent unless the client is 230 authenticated 232 Figure 3 234 Figure 1 shows all messages involved in the TLS key establishment 235 protocol (aka full handshake). The addition of ECC has direct impact 236 only on the ClientHello, the ServerHello, the server's Certificate 237 message, the ServerKeyExchange, the ClientKeyExchange, the 238 CertificateRequest, the client's Certificate message, and the 239 CertificateVerify. Next, we describe each ECC key exchange algorithm 240 in greater detail in terms of the content and processing of these 241 messages. For ease of exposition, we defer discussion of client 242 authentication and associated messages (identified with a + in Figure 243 1) until Section 3 and of the optional ECC-specific extensions (which 244 impact the Hello messages) until Section 4. 246 2.1 ECDH_ECDSA 248 In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable 249 public key and be signed with ECDSA. 251 A ServerKeyExchange MUST NOT be sent (the server's certificate 252 contains all the necessary keying information required by the client 253 to arrive at the premaster secret). 255 The client MUST generate an ECDH key pair on the same curve as the 256 server's long-term public key and send its public key in the 257 ClientKeyExchange message (except when using client authentication 258 algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the 259 modifications from section Section 3.2 or Section 3.3 apply). 261 Both client and server MUST perform an ECDH operation and use the 262 resultant shared secret as the premaster secret. All ECDH 263 calculations are performed as specified in Section 5.10 265 2.2 ECDHE_ECDSA 267 In ECDHE_ECDSA, the server's certificate MUST contain an 268 ECDSA-capable public key and be signed with ECDSA. 270 The server MUST send its ephemeral ECDH public key and a 271 specification of the corresponding curve in the ServerKeyExchange 272 message. These parameters MUST be signed with ECDSA using the 273 private key corresponding to the public key in the server's 274 Certificate. 276 The client MUST generate an ECDH key pair on the same curve as the 277 server's ephemeral ECDH key and send its public key in the 278 ClientKeyExchange message. 280 Both client and server MUST perform an ECDH operation (Section 5.10) 281 and use the resultant shared secret as the premaster secret. 283 2.3 ECDH_RSA 285 This key exchange algorithm is the same as ECDH_ECDSA except the 286 server's certificate MUST be signed with RSA rather than ECDSA. 288 2.4 ECDHE_RSA 290 This key exchange algorithm is the same as ECDHE_ECDSA except the 291 server's certificate MUST contain an RSA public key authorized for 292 signing and the signature in the ServerKeyExchange message MUST be 293 computed with the corresponding RSA private key. The server 294 certificate MUST be signed with RSA. 296 2.5 ECDH_anon 298 In ECDH_anon, the server's Certificate, the CertificateRequest, the 299 client's Certificate, and the CertificateVerify messages MUST NOT be 300 sent. 302 The server MUST send an ephemeral ECDH public key and a specification 303 of the corresponding curve in the ServerKeyExchange message. These 304 parameters MUST NOT be signed. 306 The client MUST generate an ECDH key pair on the same curve as the 307 server's ephemeral ECDH key and send its public key in the 308 ClientKeyExchange message. 310 Both client and server MUST perform an ECDH operation and use the 311 resultant shared secret as the premaster secret. All ECDH 312 calculations are performed as specified in Section 5.10 314 3. Client Authentication 316 This document defines three new client authentication mechanisms 317 named after the type of client certificate involved: ECDSA_sign, 318 ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is 319 usable with any of the non-anonymous ECC key exchange algorithms 320 described in Section 2 as well as other non-anonymous (non-ECC) key 321 exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and 322 RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. 323 Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the 324 use of a long-term ECDH client key would jeopardize the forward 325 secrecy property of these algorithms. 327 The server can request ECC-based client authentication by including 328 one or more of these certificate types in its CertificateRequest 329 message. The server MUST NOT include any certificate types that are 330 prohibited for the negotiated key exchange algorithm. The client 331 must check if it possesses a certificate appropriate for any of the 332 methods suggested by the server and is willing to use it for 333 authentication. 335 If these conditions are not met, the client should send a client 336 Certificate message containing no certificates. In this case, the 337 ClientKeyExchange should be sent as described in Section 2 and the 338 CertificateVerify should not be sent. If the server requires client 339 authentication, it may respond with a fatal handshake failure alert. 341 If the client has an appropriate certificate and is willing to use it 342 for authentication, it MUST send that certificate in the client's 343 Certificate message (as per Section 5.6) and prove possession of the 344 private key corresponding to the certified key. The process of 345 determining an appropriate certificate and proving possession is 346 different for each authentication mechanism and described below. 348 NOTE: It is permissible for a server to request (and the client to 349 send) a client certificate of a different type than the server 350 certificate. 352 3.1 ECDSA_sign 354 To use this authentication mechanism, the client MUST possess a 355 certificate containing an ECDSA-capable public key and signed with 356 ECDSA. 358 The client MUST prove possession of the private key corresponding to 359 the certified key by including a signature in the CertificateVerify 360 message as described in Section 5.8. 362 3.2 ECDSA_fixed_ECDH 364 To use this authentication mechanism, the client MUST possess a 365 certificate containing an ECDH-capable public key and that 366 certificate MUST be signed with ECDSA. Furthermore, the client's 367 ECDH key MUST be on the same elliptic curve as the server's long-term 368 (certified) ECDH key. This might limit use of this mechanism to 369 closed environments. In situations where the client has an ECC key 370 on a different curve, it would have to authenticate either using 371 ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for 372 both servers and clients is computationally more efficient than 373 mechanisms providing forward secrecy. 375 When using this authentication mechanism, the client MUST send an 376 empty ClientKeyExchange as described in Section 5.7 and MUST NOT send 377 the CertificateVerify message. The ClientKeyExchange is empty since 378 the client's ECDH public key required by the server to compute the 379 premaster secret is available inside the client's certificate. The 380 client's ability to arrive at the same premaster secret as the server 381 (demonstrated by a successful exchange of Finished messages) proves 382 possession of the private key corresponding to the certified public 383 key and the CertificateVerify message is unnecessary. 385 3.3 RSA_fixed_ECDH 387 This authentication mechanism is identical to ECDSA_fixed_ECDH except 388 the client's certificate MUST be signed with RSA. 390 4. TLS Extensions for ECC 392 Two new TLS extensions --- (i) the Supported Elliptic Curves 393 Extension, and (ii) the Supported Point Formats Extension --- allow a 394 client to negotiate the use of specific curves and point formats 395 (e.g. compressed v/s uncompressed), respectively. These extensions 396 are especially relevant for constrained clients that may only support 397 a limited number of curves or point formats. They follow the general 398 approach outlined in [3]. The client enumerates the curves and point 399 formats it supports by including the appropriate extensions in its 400 ClientHello message. By echoing that extension in its ServerHello, 401 the server agrees to restrict its key selection or encoding to the 402 choices specified by the client. 404 A TLS client that proposes ECC cipher suites in its ClientHello 405 message SHOULD include these extensions. Servers implementing ECC 406 cipher suites MUST support these extensions and negotiate the use of 407 an ECC cipher suite only if they can complete the handshake while 408 limiting themselves to the curves and compression techniques 409 enumerated by the client. This eliminates the possibility that a 410 negotiated ECC handshake will be subsequently aborted due to a 411 client's inability to deal with the server's EC key. 413 These extensions MUST NOT be included if the client does not propose 414 any ECC cipher suites. A client that proposes ECC cipher suites may 415 choose not to include these extension. In this case, the server is 416 free to choose any one of the elliptic curves or point formats listed 417 in Section 5. That section also describes the structure and 418 processing of these extensions in greater detail. 420 5. Data Structures and Computations 422 This section specifies the data structures and computations used by 423 ECC-based key mechanisms specified in Section 2, Section 3 and 424 Section 4. The presentation language used here is the same as that 425 used in TLS [2]. Since this specification extends TLS, these 426 descriptions should be merged with those in the TLS specification and 427 any others that extend TLS. This means that enum types may not 428 specify all possible values and structures with multiple formats 429 chosen with a select() clause may not indicate all possible cases. 431 5.1 Client Hello Extensions 433 When this message is sent: 435 The ECC extensions SHOULD be sent along with any ClientHello message 436 that proposes ECC cipher suites. 438 Meaning of this message: 440 These extensions allow a constrained client to enumerate the elliptic 441 curves and/or point formats it supports. 443 Structure of this message: 445 The general structure of TLS extensions is described in [3] and this 446 specification adds two new types to ExtensionType. 448 enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType; 450 elliptic_curves: Indicates the set of elliptic curves supported by 451 the client. For this extension, the opaque extension_data field 452 contains EllipticCurveList. 453 ec_point_formats: Indicates the set of point formats supported by 454 the client. For this extension, the opaque extension_data field 455 contains ECPointFormatList. 457 enum { 458 sect163k1 (1), sect163r1 (2), sect163r2 (3), 459 sect193r1 (4), sect193r2 (5), sect233k1 (6), 460 sect233r1 (7), sect239k1 (8), sect283k1 (9), 461 sect283r1 (10), sect409k1 (11), sect409r1 (12), 462 sect571k1 (13), sect571r1 (14), secp160k1 (15), 463 secp160r1 (16), secp160r2 (17), secp192k1 (18), 464 secp192r1 (19), secp224k1 (20), secp224r1 (21), 465 secp256k1 (22), secp256r1 (23), secp384r1 (24), 466 secp521r1 (25), reserved (240..247), 467 arbitrary_explicit_prime_curves(253), 468 arbitrary_explicit_char2_curves(254), 469 (255) 470 } NamedCurve; 472 sect163k1, etc: Indicates support of the corresponding named curve 473 specified in SEC 2 [10]. Note that many of these curves are also 474 recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240 475 through 247 are reserved for private use. Values 253 and 254 476 indicate that the client supports arbitrary prime and 477 characteristic-2 curves, respectively (the curve parameters must 478 be encoded explicitly in ECParameters). 480 struct { 481 NamedCurve elliptic_curve_list<1..2^8-1> 482 } EllipticCurveList; 484 Items in elliptic_curve_list are ordered according to the client's 485 preferences (favorite choice first). 487 As an example, a client that only supports secp192r1 (aka NIST P-192) 488 and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would 489 include an elliptic_curves extension with the following octets: 491 00 ?? 02 13 15 493 A client that supports arbitrary explicit binary polynomial curves 494 would include an extension with the following octets: 496 00 ?? 01 fe 497 enum { uncompressed (0), ansiX963_compressed (1), 498 ansiX963_hybrid (2), (255) 499 } ECPointFormat; 501 struct { 502 ECPointFormat ec_point_format_list<1..2^8-1> 503 } ECPointFormatList; 505 Three point formats are included in the defintion of ECPointFormat 506 above. The uncompressed point format is the default format that 507 implementations of this document MUST support. The 508 ansix963_compressed format reduces bandwidth by including only the 509 x-coordinate and a single bit of the y-coordinate of the point. The 510 ansix963_hybrid format includes both the full y-coordinate and the 511 compressed y-coordinate to allow flexibility and improve efficiency 512 in some cases. Implementations of this document MAY support the 513 ansix963_compressed and ansix963_hybrid point formats. 515 Items in ec_point_format_list are ordered according to the client's 516 preferences (favorite choice first). 518 A client that only supports the uncompressed point format includes an 519 extension with the following octets: 521 00 ?? 01 00 523 A client that prefers the use of the ansiX963_compressed format over 524 uncompressed may indicate that preference by including an extension 525 with the following octets: 527 00 ?? 02 01 00 529 Actions of the sender: 531 A client that proposes ECC cipher suites in its ClientHello appends 532 these extensions (along with any others) enumerating the curves and 533 point formats it supports. 535 Actions of the receiver: 537 A server that receives a ClientHello containing one or both of these 538 extensions MUST use the client's enumerated capabilities to guide its 539 selection of an appropriate cipher suite. One of the proposed ECC 540 cipher suites must be negotiated only if the server can successfully 541 complete the handshake while using the curves and point formats 542 supported by the client. 544 NOTE: A server participating in an ECDHE-ECDSA key exchange may use 545 different curves for (i) the ECDSA key in its certificate, and (ii) 546 the ephemeral ECDH key in the ServerKeyExchange message. The server 547 must consider the "elliptic_curves" extension in selecting both of 548 these curves. 550 If a server does not understand the "elliptic_curves" extension or is 551 unable to complete the ECC handshake while restricting itself to the 552 enumerated curves, it MUST NOT negotiate the use of an ECC cipher 553 suite. Depending on what other cipher suites are proposed by the 554 client and supported by the server, this may result in a fatal 555 handshake failure alert due to the lack of common cipher suites. 557 5.2 Server Hello Extensions 559 When this message is sent: 561 The ServerHello ECC extensions are sent in response to a Client Hello 562 message containing ECC extensions when negotiating an ECC cipher 563 suite. 565 Meaning of this message: 567 These extensions indicate the server's agreement to use only the 568 elliptic curves and point formats supported by the client during the 569 ECC-based key exchange. 571 Structure of this message: 573 The ECC extensions echoed by the server are the same as those in the 574 ClientHello except the "extension_data" field is empty. 576 For example, a server indicates its acceptance of the client's 577 elliptic_curves extension by sending an extension with the following 578 octets: 580 00 ?? 00 00 582 Actions of the sender: 584 A server makes sure that it can complete a proposed ECC key exchange 585 mechanism by restricting itself to the curves/point formats supported 586 by the client before sending these extensions. 588 Actions of the receiver: 590 A client that receives a ServerHello with ECC extensions proceeds 591 with an ECC key exchange assured that it will be able to handle the 592 server's EC key(s). 594 5.3 Server Certificate 596 When this message is sent: 598 This message is sent in all non-anonymous ECC-based key exchange 599 algorithms. 601 Meaning of this message: 603 This message is used to authentically convey the server's static 604 public key to the client. The following table shows the server 605 certificate type appropriate for each key exchange algorithm. ECC 606 public keys must be encoded in certificates as described in Section 607 5.9. 609 NOTE: The server's Certificate message is capable of carrying a chain 610 of certificates. The restrictions mentioned in Table 3 apply only to 611 the server's certificate (first in the chain). 613 Key Exchange Algorithm Server Certificate Type 614 ---------------------- ----------------------- 616 ECDH_ECDSA Certificate must contain an 617 ECDH-capable public key. It 618 must be signed with ECDSA. 620 ECDHE_ECDSA Certificate must contain an 621 ECDSA-capable public key. It 622 must be signed with ECDSA. 624 ECDH_RSA Certificate must contain an 625 ECDH-capable public key. It 626 must be signed with RSA. 628 ECDHE_RSA Certificate must contain an 629 RSA public key authorized for 630 use in digital signatures. It 631 must be signed with RSA. 633 Table 3: Server certificate types 635 Structure of this message: 637 Identical to the TLS Certificate format. 639 Actions of the sender: 641 The server constructs an appropriate certificate chain and conveys it 642 to the client in the Certificate message. 644 Actions of the receiver: 646 The client validates the certificate chain, extracts the server's 647 public key, and checks that the key type is appropriate for the 648 negotiated key exchange algorithm. 650 5.4 Server Key Exchange 652 When this message is sent: 654 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and 655 ECDH_anon key exchange algorithms. 657 Meaning of this message: 659 This message is used to convey the server's ephemeral ECDH public key 660 (and the corresponding elliptic curve domain parameters) to the 661 client. 663 Structure of this message: 665 enum { explicit_prime (1), explicit_char2 (2), 666 named_curve (3), (255) } ECCurveType; 668 explicit_prime: Indicates the elliptic curve domain parameters are 669 conveyed verbosely, and the underlying finite field is a prime 670 field. 671 explicit_char2: Indicates the elliptic curve domain parameters are 672 conveyed verbosely, and the underlying finite field is a 673 characteristic-2 field. 674 named_curve: Indicates that a named curve is used. This option 675 SHOULD be used when applicable. 677 struct { 678 opaque a <1..2^8-1>; 679 opaque b <1..2^8-1>; 680 } ECCurve; 682 a, b: These parameters specify the coefficients of the elliptic 683 curve. Each value contains the byte string representation of a 684 field element following the conversion routine in Section 4.3.3 of 685 ANSI X9.62 [6]. 687 struct { 688 opaque point <1..2^8-1>; 690 } ECPoint; 692 point: This is the byte string representation of an elliptic curve 693 point following the conversion routine in Section 4.3.6 of ANSI 694 X9.62 [6]. Note that this byte string may represent an elliptic 695 curve point in compressed or uncompressed form. 697 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 699 ec_basis_trinomial: Indicates representation of a characteristic-2 700 field using a trinomial basis. 701 ec_basis_pentanomial: Indicates representation of a characteristic-2 702 field using a pentanomial basis. 704 struct { 705 ECCurveType curve_type; 706 select (curve_type) { 707 case explicit_prime: 708 opaque prime_p <1..2^8-1>; 709 ECCurve curve; 710 ECPoint base; 711 opaque order <1..2^8-1>; 712 opaque cofactor <1..2^8-1>; 713 case explicit_char2: 714 uint16 m; 715 ECBasisType basis; 716 select (basis) { 717 case ec_trinomial: 718 opaque k <1..2^8-1>; 719 case ec_pentanomial: 720 opaque k1 <1..2^8-1>; 721 opaque k2 <1..2^8-1>; 722 opaque k3 <1..2^8-1>; 723 }; 724 ECCurve curve; 725 ECPoint base; 726 opaque order <1..2^8-1>; 727 opaque cofactor <1..2^8-1>; 728 case named_curve: 729 NamedCurve namedcurve; 730 }; 731 } ECParameters; 733 curve_type: This identifies the type of the elliptic curve domain 734 parameters. 736 prime_p: This is the odd prime defining the field Fp. 737 curve: Specifies the coefficients a and b of the elliptic curve E. 738 base: Specifies the base point G on the elliptic curve. 739 order: Specifies the order n of the base point. 740 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) 741 represents the number of points on the elliptic curve E defined 742 over the field Fq. 743 m: This is the degree of the characteristic-2 field F2^m. 744 k: The exponent k for the trinomial basis representation x^m + x^k 745 +1. 746 k1, k2, k3: The exponents for the pentanomial representation x^m + 747 x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). 748 namedcurve: Specifies a recommended set of elliptic curve domain 749 parameters. All enum values of NamedCurve are allowed except for 750 arbitrary_explicit_prime_curves(253) and 751 arbitrary_explicit_char2_curves(254). These two values are only 752 allowed in the ClientHello extension. 754 struct { 755 ECParameters curve_params; 756 ECPoint public; 757 } ServerECDHParams; 759 curve_params: Specifies the elliptic curve domain parameters 760 associated with the ECDH public key. 761 public: The ephemeral ECDH public key. 763 The ServerKeyExchange message is extended as follows. 765 enum { ec_diffie_hellman } KeyExchangeAlgorithm; 767 ec_diffie_hellman: Indicates the ServerKeyExchange message contains 768 an ECDH public key. 770 select (KeyExchangeAlgorithm) { 771 case ec_diffie_hellman: 772 ServerECDHParams params; 773 Signature signed_params; 774 } ServerKeyExchange; 776 params: Specifies the ECDH public key and associated domain 777 parameters. 778 signed_params: A hash of the params, with the signature appropriate 779 to that hash applied. The private key corresponding to the 780 certified public key in the server's Certificate message is used 781 for signing. 783 enum { ecdsa } SignatureAlgorithm; 784 select (SignatureAlgorithm) { 785 case ecdsa: 786 digitally-signed struct { 787 opaque sha_hash[sha_size]; 788 }; 789 } Signature; 791 NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange 792 algorithm and 'anonymous' for ECDH_anon. These cases are defined in 793 TLS [2]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA 794 signatures are generated and verified as described in Section 5.10. 795 As per ANSI X9.62, an ECDSA signature consists of a pair of integers 796 r and s. These integers are both converted into byte strings of the 797 same length as the curve order n using the conversion routine 798 specified in Section 4.3.1 of [6]. The two byte strings are 799 concatenated, and the result is placed in the signature field. 801 Actions of the sender: 803 The server selects elliptic curve domain parameters and an ephemeral 804 ECDH public key corresponding to these parameters according to the 805 ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to 806 the client in the ServerKeyExchange message using the format defined 807 above. 809 Actions of the recipient: 811 The client verifies the signature (when present) and retrieves the 812 server's elliptic curve domain parameters and ephemeral ECDH public 813 key from the ServerKeyExchange message. 815 5.5 Certificate Request 817 When this message is sent: 819 This message is sent when requesting client authentication. 821 Meaning of this message: 823 The server uses this message to suggest acceptable client 824 authentication methods. 826 Structure of this message: 828 The TLS CertificateRequest message is extended as follows. 830 enum { 831 ecdsa_sign(?), rsa_fixed_ecdh(?), 832 ecdsa_fixed_ecdh(?), (255) 833 } ClientCertificateType; 835 ecdsa_sign, etc Indicates that the server would like to use the 836 corresponding client authentication method specified in Section 3. 837 EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and 838 ecdsa_fixed_ecdh have been left as ?. These values will be 839 assigned when this draft progresses to RFC. Earlier versions of 840 this draft used the values 5, 6, and 7 - however these values have 841 been removed since they are used differently by SSL 3.0 [13] and 842 their use by TLS is being deprecated. 844 Actions of the sender: 846 The server decides which client authentication methods it would like 847 to use, and conveys this information to the client using the format 848 defined above. 850 Actions of the receiver: 852 The client determines whether it has an appropriate certificate for 853 use with any of the requested methods, and decides whether or not to 854 proceed with client authentication. 856 5.6 Client Certificate 858 When this message is sent: 860 This message is sent in response to a CertificateRequest when a 861 client has a suitable certificate. 863 Meaning of this message: 865 This message is used to authentically convey the client's static 866 public key to the server. The following table summarizes what client 867 certificate types are appropriate for the ECC-based client 868 authentication mechanisms described in Section 3. ECC public keys 869 must be encoded in certificates as described in Section 5.9. 871 NOTE: The client's Certificate message is capable of carrying a chain 872 of certificates. The restrictions mentioned in Table 4 apply only to 873 the client's certificate (first in the chain). 875 Client 876 Authentication Method Client Certificate Type 877 --------------------- ----------------------- 879 ECDSA_sign Certificate must contain an 880 ECDSA-capable public key and 881 be signed with ECDSA. 883 ECDSA_fixed_ECDH Certificate must contain an 884 ECDH-capable public key on the 885 same elliptic curve as the server's 886 long-term ECDH key. This certificate 887 must be signed with ECDSA. 889 RSA_fixed_ECDH Certificate must contain an 890 ECDH-capable public key on the 891 same elliptic curve as the server's 892 long-term ECDH key. This certificate 893 must be signed with RSA. 895 Table 4: Client certificate types 897 Structure of this message: 899 Identical to the TLS client Certificate format. 901 Actions of the sender: 903 The client constructs an appropriate certificate chain, and conveys 904 it to the server in the Certificate message. 906 Actions of the receiver: 908 The TLS server validates the certificate chain, extracts the client's 909 public key, and checks that the key type is appropriate for the 910 client authentication method. 912 5.7 Client Key Exchange 914 When this message is sent: 916 This message is sent in all key exchange algorithms. If client 917 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 918 message is empty. Otherwise, it contains the client's ephemeral ECDH 919 public key. 921 Meaning of the message: 923 This message is used to convey ephemeral data relating to the key 924 exchange belonging to the client (such as its ephemeral ECDH public 925 key). 927 Structure of this message: 929 The TLS ClientKeyExchange message is extended as follows. 931 enum { yes, no } EphemeralPublicKey; 933 yes, no: Indicates whether or not the client is providing an 934 ephemeral ECDH public key. (In ECC ciphersuites, this is "yes" 935 except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH 936 client authentication mechanism.) 938 struct { 939 select (EphemeralPublicKey) { 940 case yes: ECPoint ecdh_Yc; 941 case no: struct { }; 942 } ecdh_public; 943 } ClientECDiffieHellmanPublic; 945 ecdh_Yc: Contains the client's ephemeral ECDH public key. 947 struct { 948 select (KeyExchangeAlgorithm) { 949 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 950 } exchange_keys; 951 } ClientKeyExchange; 953 Actions of the sender: 955 The client selects an ephemeral ECDH public key corresponding to the 956 parameters it received from the server according to the ECKAS-DH1 957 scheme from IEEE 1363 [5]. It conveys this information to the client 958 in the ClientKeyExchange message using the format defined above. 960 Actions of the recipient: 962 The server retrieves the client's ephemeral ECDH public key from the 963 ClientKeyExchange message and checks that it is on the same elliptic 964 curve as the server's ECDH key. 966 5.8 Certificate Verify 968 When this message is sent: 970 This message is sent when the client sends a client certificate 971 containing a public key usable for digital signatures, e.g. when the 972 client is authenticated using the ECDSA_sign mechanism. 974 Meaning of the message: 976 This message contains a signature that proves possession of the 977 private key corresponding to the public key in the client's 978 Certificate message. 980 Structure of this message: 982 The TLS CertificateVerify message is extended as follows. 984 enum { ecdsa } SignatureAlgorithm; 986 select (SignatureAlgorithm) { 987 case ecdsa: 988 digitally-signed struct { 989 opaque sha_hash[sha_size]; 990 }; 991 } Signature; 993 For the ecdsa case, the signature field in the CertificateVerify 994 message contains an ECDSA signature computed over handshake messages 995 exchanged so far. ECDSA signatures are computed as described in 996 Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a 997 pair of integers r and s. These integers are both converted into 998 byte strings of the same length as the curve order n using the 999 conversion routine specified in Section 4.3.1 of [6]. The two byte 1000 strings are concatenated, and the result is placed in the signature 1001 field. 1003 Actions of the sender: 1005 The client computes its signature over all handshake messages sent or 1006 received starting at client hello up to but not including this 1007 message. It uses the private key corresponding to its certified 1008 public key to compute the signature which is conveyed in the format 1009 defined above. 1011 Actions of the receiver: 1013 The server extracts the client's signature from the CertificateVerify 1014 message, and verifies the signature using the public key it received 1015 in the client's Certificate message. 1017 5.9 Elliptic Curve Certificates 1019 X509 certificates containing ECC public keys or signed using ECDSA 1020 MUST comply with [11] or another RFC that replaces or extends it. 1021 Clients SHOULD use the elliptic curve domain parameters recommended 1022 in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. 1024 5.10 ECDH, ECDSA and RSA Computations 1026 All ECDH calculations (including parameter and key generation as well 1027 as the shared secret calculation) MUST be performed according to [5] 1028 using the ECKAS-DH1 scheme with the identity map as key derivation 1029 function, so that the premaster secret is the x-coordinate of the 1030 ECDH shared secret elliptic curve point, i.e. the octet string Z in 1031 IEEE 1363 terminology. 1033 Note that a new extension may be introduced in the future to allow 1034 the use of a different KDF during computation of the premaster 1035 secret. In this event, the new KDF would be used in place of the 1036 process detailed above. This may be desirable, for example, to 1037 support compatibility with the planned NIST key agreement standard. 1039 All ECDSA computations MUST be performed according to ANSI X9.62 [6] 1040 or its successors. Data to be signed/verified is hashed and the 1041 result run directly through the ECDSA algorithm with no additional 1042 hashing. The default hash function is SHA-1 [7] and sha_size (see 1043 Section 5.4 and Section 5.8) is 20. However, an alternative hash 1044 function, such as one of the new SHA hash functions specified in FIPS 1045 180-2 [7], may be used instead if the certificate containing the EC 1046 public key explicitly requires use of another hash function. (The 1047 mechanism for specifying the required hash function has not been 1048 standardized but this provision anticipates such standardization and 1049 obviates the need to update this document in response. Future PKIX 1050 RFCs may choose, for example, to specify the hash function to be used 1051 with a public key in the parameters field of subjectPublicKeyInfo.) 1053 All RSA signatures must be generated and verified according to PKCS#1 1054 [9]. 1056 6. Cipher Suites 1058 The table below defines new ECC cipher suites that use the key 1059 exchange algorithms specified in Section 2. 1061 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1062 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1063 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } 1064 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1065 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1066 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1068 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1069 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1070 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1071 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1072 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1074 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1075 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1076 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1077 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1078 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1080 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1081 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1082 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1083 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1084 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1086 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } 1087 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } 1088 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1089 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1090 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1092 Table 5: TLS ECC cipher suites 1094 Figure 30 1096 The key exchange method, cipher, and hash algorithm for each of these 1097 cipher suites are easily determined by examining the name. Ciphers 1098 other than AES ciphers, and hash algorithms are defined in [2]. AES 1099 ciphers are defined in [14]. 1101 Server implementations SHOULD support all of the following cipher 1102 suites, and client implementations SHOULD support at least one of 1103 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 1104 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 1105 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 1106 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 1108 7. Security Considerations 1110 This document is based on [2], [5], [6] and [14]. The appropriate 1111 security considerations of those documents apply. 1113 One important issue that implementors and users must consider is 1114 elliptic curve selection. Guidance on selecting an appropriate 1115 elliptic curve size is given in Figure 1. 1117 Beyond elliptic curve size, the main issue is elliptic curve 1118 structure. As a general principle, it is more conservative to use 1119 elliptic curves with as little algebraic structure as possible - thus 1120 random curves are more conservative than special curves such as 1121 Koblitz curves, and curves over F_p with p random are more 1122 conservative than curves over F_p with p of a special form (and 1123 curves over F_p with p random might be considered more conservative 1124 than curves over F_2^m as there is no choice between multiple fields 1125 of similar size for characteristic 2). Note, however, that algebraic 1126 structure can also lead to implementation efficiencies and 1127 implementors and users may, therefore, need to balance conservatism 1128 against a need for efficiency. Concrete attacks are known against 1129 only very few special classes of curves, such as supersingular 1130 curves, and these classes are excluded from the ECC standards that 1131 this document references [5], [6]. 1133 Another issue is the potential for catastrophic failures when a 1134 single elliptic curve is widely used. In this case, an attack on the 1135 elliptic curve might result in the compromise of a large number of 1136 keys. Again, this concern may need to be balanced against efficiency 1137 and interoperability improvements associated with widely-used curves. 1138 Substantial additional information on elliptic curve choice can be 1139 found in [4], [5], [6], [8]. 1141 Implementors and users must also consider whether they need forward 1142 secrecy. Forward secrecy refers to the property that session keys 1143 are not compromised if the static, certified keys belonging to the 1144 server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key 1145 exchange algorithms provide forward secrecy protection in the event 1146 of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. 1147 Similarly if the client is providing a static, certified key, 1148 ECDSA_sign client authentication provides forward secrecy protection 1149 in the event of client key compromise, while ECDSA_fixed_ECDH and 1150 RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy 1151 protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, 1152 with ECDSA_sign used for client authentication if necessary. Here 1153 again the security benefits of forward secrecy may need to be 1154 balanced against the improved efficiency offered by other options. 1156 8. Acknowledgments 1158 The authors wish to thank Bill Anderson and Tim Dierks. 1160 9. References 1162 9.1 Normative References 1164 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 1165 Levels", RFC 2119, March 1997. 1167 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1168 2246, January 1999. 1170 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and 1171 T. Wright, "Transport Layer Security (TLS) Extensions", 1172 draft-ietf-tls-rfc3546bis-00.txt (work in progress), Nov. 2004. 1174 [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, 1175 . 1177 [5] IEEE, "Standard Specifications for Public Key Cryptography", 1178 IEEE 1363, 2000. 1180 [6] ANSI, "Public Key Cryptography For The Financial Services 1181 Industry: The Elliptic Curve Digital Signature Algorithm 1182 (ECDSA)", ANSI X9.62, 1998. 1184 [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 1186 [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1188 [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1189 1.5", PKCS 1, November 1993. 1191 [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 1192 2000, . 1194 [11] Polk, T., Housley, R. and L. Bassham, "Algorithms and 1195 Identifiers for the Internet X.509 Public Key Infrastructure 1196 Certificate and Certificate Revocation List (CRL) Profile", RFC 1197 3279, April 2002. 1199 9.2 Informative References 1201 [12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1202 Sizes", Journal of Cryptology 14 (2001) 255-293, 1203 . 1205 [13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol 1206 Version 3.0", November 1996, 1207 . 1209 [14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1210 Transport Layer Security (TLS)", RFC 3268, June 2002. 1212 [15] Hovey, R. and S. Bradner, "The Organizations Involved in the 1213 IETF Standards Process", RFC 2028, BCP 11, October 1996. 1215 Authors' Addresses 1217 Vipul Gupta 1218 Sun Microsystems Laboratories 1219 16 Network Circle 1220 MS UMPK16-160 1221 Menlo Park, CA 94025 1222 USA 1224 Phone: +1 650 786 7551 1225 EMail: vipul.gupta@sun.com 1227 Simon Blake-Wilson 1228 Basic Commerce & Industries, Inc. 1229 96 Spandia Ave 1230 Unit 606 1231 Toronto, ON M6G 2T6 1232 Canada 1234 Phone: +1 416 214 5961 1235 EMail: sblakewilson@bcisse.com 1237 Bodo Moeller 1238 University of California, Berkeley 1239 EECS -- Computer Science Division 1240 513 Soda Hall 1241 Berkeley, CA 94720-1776 1242 USA 1244 EMail: bodo@openssl.org 1246 Chris Hawk 1247 Corriente Networks 1249 EMail: chris@corriente.net 1250 Nelson Bolyard 1252 EMail: nelson@bolyard.com 1254 Intellectual Property Statement 1256 The IETF takes no position regarding the validity or scope of any 1257 Intellectual Property Rights or other rights that might be claimed to 1258 pertain to the implementation or use of the technology described in 1259 this document or the extent to which any license under such rights 1260 might or might not be available; nor does it represent that it has 1261 made any independent effort to identify any such rights. Information 1262 on the procedures with respect to rights in RFC documents can be 1263 found in BCP 78 and BCP 79. 1265 Copies of IPR disclosures made to the IETF Secretariat and any 1266 assurances of licenses to be made available, or the result of an 1267 attempt made to obtain a general license or permission for the use of 1268 such proprietary rights by implementers or users of this 1269 specification can be obtained from the IETF on-line IPR repository at 1270 http://www.ietf.org/ipr. 1272 The IETF invites any interested party to bring to its attention any 1273 copyrights, patents or patent applications, or other proprietary 1274 rights that may cover technology that may be required to implement 1275 this standard. Please address the information to the IETF at 1276 ietf-ipr@ietf.org. 1278 Disclaimer of Validity 1280 This document and the information contained herein are provided on an 1281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1283 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1284 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1285 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1288 Copyright Statement 1290 Copyright (C) The Internet Society (2004). This document is subject 1291 to the rights, licenses and restrictions contained in BCP 78, and 1292 except as set forth therein, the authors retain all their rights. 1294 Acknowledgment 1296 Funding for the RFC Editor function is currently provided by the 1297 Internet Society.