idnits 2.17.00 (12 Aug 2021) /tmp/idnits5687/draft-ietf-tls-ecc-08.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 1285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1275. ** 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 704 has weird spacing: '...rveType cur...' == Line 717 has weird spacing: '... opaque k <1....' == Line 719 has weird spacing: '... opaque k1 <1...' == Line 720 has weird spacing: '... opaque k2 <1...' == Line 721 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 221 == Unused Reference: '15' is defined on line 1211, 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: September 2, 2005 S. Blake-Wilson 5 BCI 6 B. Moeller 7 University of Calgary 8 C. Hawk 9 Corriente Networks 10 N. Bolyard 11 Mar. 2005 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 September 2, 2005. 43 Copyright Notice 45 Copyright (C) The Internet Society (2005). 47 Abstract 48 This document describes new key exchange algorithms based on Elliptic 49 Curve Cryptography (ECC) for the TLS (Transport Layer Security) 50 protocol. In particular, it specifies the use of Elliptic Curve 51 Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of 52 Elliptic Curve Digital Signature Algorithm (ECDSA) as a new 53 authentication mechanism. 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [1]. 59 Please send comments on this document to the TLS mailing list. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5 65 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9 71 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 73 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 74 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 75 5. Data Structures and Computations . . . . . . . . . . . . . . 12 76 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 77 5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . 15 78 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16 79 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 17 80 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 20 81 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 21 82 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 22 83 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 23 84 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 25 85 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 25 86 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 26 87 7. Security Considerations . . . . . . . . . . . . . . . . . . 28 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 90 9.1 Normative References . . . . . . . . . . . . . . . . . . . 30 91 9.2 Informative References . . . . . . . . . . . . . . . . . . 30 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 93 Intellectual Property and Copyright Statements . . . . . . . 33 95 1. Introduction 97 Elliptic Curve Cryptography (ECC) is emerging as an attractive 98 public-key cryptosystem for mobile/wireless environments. Compared 99 to currently prevalent cryptosystems such as RSA, ECC offers 100 equivalent security with smaller key sizes. This is illustrated in 101 the following table, based on [12], which gives approximate 102 comparable key sizes for symmetric- and asymmetric-key cryptosystems 103 based on the best-known algorithms for attacking them. 105 Symmetric | ECC | DH/DSA/RSA 106 -------------+---------+------------ 107 80 | 163 | 1024 108 112 | 233 | 2048 109 128 | 283 | 3072 110 192 | 409 | 7680 111 256 | 571 | 15360 113 Table 1: Comparable key sizes (in bits) 115 Figure 1 117 Smaller key sizes result in power, bandwidth and computational 118 savings that make ECC especially attractive for constrained 119 environments. 121 This document describes additions to TLS to support ECC. In 122 particular, it defines 123 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement 124 scheme with long-term or ephemeral keys to establish the TLS 125 premaster secret, and 126 o the use of fixed-ECDH certificates and ECDSA for authentication of 127 TLS peers. 129 The remainder of this document is organized as follows. Section 2 130 provides an overview of ECC-based key exchange algorithms for TLS. 131 Section 3 describes the use of ECC certificates for client 132 authentication. TLS extensions that allow a client to negotiate the 133 use of specific curves and point formats are presented in Section 4. 134 Section 5 specifies various data structures needed for an ECC-based 135 handshake, their encoding in TLS messages and the processing of those 136 messages. Section 6 defines new ECC-based cipher suites and 137 identifies a small subset of these as recommended for all 138 implementations of this specification. Section 7 and Section 8 139 mention security considerations and acknowledgments, respectively. 140 This is followed by a list of references cited in this document, the 141 authors' contact information, and statements on intellectual property 142 rights and copyrights. 144 Implementation of this specification requires familiarity with TLS 145 [2], TLS extensions [3] and ECC [4][5][6][8] . 147 2. Key Exchange Algorithms 149 This document introduces five new ECC-based key exchange algorithms 150 for TLS. All of them use ECDH to compute the TLS premaster secret 151 and differ only in the lifetime of ECDH keys (long-term or ephemeral) 152 and the mechanism (if any) used to authenticate them. The derivation 153 of the TLS master secret from the premaster secret and the subsequent 154 generation of bulk encryption/MAC keys and initialization vectors is 155 independent of the key exchange algorithm and not impacted by the 156 introduction of ECC. 158 The table below summarizes the new key exchange algorithms which 159 mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [2]), 160 respectively. 162 Key 163 Exchange 164 Algorithm Description 165 --------- ----------- 167 ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. 169 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. 171 ECDH_RSA Fixed ECDH with RSA-signed certificates. 173 ECDHE_RSA Ephemeral ECDH with RSA signatures. 175 ECDH_anon Anonymous ECDH, no signatures. 177 Table 2: ECC key exchange algorithms 179 Figure 2 181 The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward 182 secrecy. With ECDHE_RSA, a server can reuse its existing RSA 183 certificate and easily comply with a constrained client's elliptic 184 curve preferences (see Section 4). However, the computational cost 185 incurred by a server is higher for ECDHE_RSA than for the traditional 186 RSA key exchange which does not provide forward secrecy. 188 The ECDH_RSA mechanism requires a server to acquire an ECC 189 certificate but the certificate issuer can still use an existing RSA 190 key for signing. This eliminates the need to update the trusted key 191 store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for 192 the server as well as the certification authority and is best suited 193 for constrained devices unable to support RSA. 195 The anonymous key exchange algorithm does not provide authentication 196 of the server or the client. Like other anonymous TLS key exchanges, 197 it is subject to man-in-the-middle attacks. Implementations of this 198 algorithm SHOULD provide authentication by other means. 200 Note that there is no structural difference between ECDH and ECDSA 201 keys. A certificate issuer may use X509.v3 keyUsage and 202 extendedKeyUsage extensions to restrict the use of an ECC public key 203 to certain computations. This document refers to an ECC key as 204 ECDH-capable if its use in ECDH is permitted. ECDSA-capable is 205 defined similarly. 207 Client Server 208 ------ ------ 210 ClientHello --------> 211 ServerHello 212 Certificate* 213 ServerKeyExchange* 214 CertificateRequest*+ 215 <-------- ServerHelloDone 216 Certificate*+ 217 ClientKeyExchange 218 CertificateVerify*+ 219 [ChangeCipherSpec] 220 Finished --------> 221 [ChangeCipherSpec] 222 <-------- Finished 224 Application Data <-------> Application Data 226 Figure 1: Message flow in a full TLS handshake 227 * message is not sent under some conditions 228 + message is not sent unless the client is 229 authenticated 231 Figure 3 233 Figure 1 shows all messages involved in the TLS key establishment 234 protocol (aka full handshake). The addition of ECC has direct impact 235 only on the ClientHello, the ServerHello, the server's Certificate 236 message, the ServerKeyExchange, the ClientKeyExchange, the 237 CertificateRequest, the client's Certificate message, and the 238 CertificateVerify. Next, we describe each ECC key exchange algorithm 239 in greater detail in terms of the content and processing of these 240 messages. For ease of exposition, we defer discussion of client 241 authentication and associated messages (identified with a + in Figure 242 1) until Section 3 and of the optional ECC-specific extensions (which 243 impact the Hello messages) until Section 4. 245 2.1 ECDH_ECDSA 247 In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable 248 public key and be signed with ECDSA. 250 A ServerKeyExchange MUST NOT be sent (the server's certificate 251 contains all the necessary keying information required by the client 252 to arrive at the premaster secret). 254 The client MUST generate an ECDH key pair on the same curve as the 255 server's long-term public key and send its public key in the 256 ClientKeyExchange message (except when using client authentication 257 algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the 258 modifications from section Section 3.2 or Section 3.3 apply). 260 Both client and server MUST perform an ECDH operation and use the 261 resultant shared secret as the premaster secret. All ECDH 262 calculations are performed as specified in Section 5.10 264 2.2 ECDHE_ECDSA 266 In ECDHE_ECDSA, the server's certificate MUST contain an 267 ECDSA-capable public key and be signed with ECDSA. 269 The server MUST send its ephemeral ECDH public key and a 270 specification of the corresponding curve in the ServerKeyExchange 271 message. These parameters MUST be signed with ECDSA using the 272 private key corresponding to the public key in the server's 273 Certificate. 275 The client MUST generate an ECDH key pair on the same curve as the 276 server's ephemeral ECDH key and send its public key in the 277 ClientKeyExchange message. 279 Both client and server MUST perform an ECDH operation (Section 5.10) 280 and use the resultant shared secret as the premaster secret. 282 2.3 ECDH_RSA 284 This key exchange algorithm is the same as ECDH_ECDSA except the 285 server's certificate MUST be signed with RSA rather than ECDSA. 287 2.4 ECDHE_RSA 289 This key exchange algorithm is the same as ECDHE_ECDSA except the 290 server's certificate MUST contain an RSA public key authorized for 291 signing and the signature in the ServerKeyExchange message MUST be 292 computed with the corresponding RSA private key. The server 293 certificate MUST be signed with RSA. 295 2.5 ECDH_anon 297 In ECDH_anon, the server's Certificate, the CertificateRequest, the 298 client's Certificate, and the CertificateVerify messages MUST NOT be 299 sent. 301 The server MUST send an ephemeral ECDH public key and a specification 302 of the corresponding curve in the ServerKeyExchange message. These 303 parameters MUST NOT be signed. 305 The client MUST generate an ECDH key pair on the same curve as the 306 server's ephemeral ECDH key and send its public key in the 307 ClientKeyExchange message. 309 Both client and server MUST perform an ECDH operation and use the 310 resultant shared secret as the premaster secret. All ECDH 311 calculations are performed as specified in Section 5.10 313 3. Client Authentication 315 This document defines three new client authentication mechanisms 316 named after the type of client certificate involved: ECDSA_sign, 317 ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is 318 usable with any of the non-anonymous ECC key exchange algorithms 319 described in Section 2 as well as other non-anonymous (non-ECC) key 320 exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and 321 RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. 322 Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the 323 use of a long-term ECDH client key would jeopardize the forward 324 secrecy property of these algorithms. 326 The server can request ECC-based client authentication by including 327 one or more of these certificate types in its CertificateRequest 328 message. The server MUST NOT include any certificate types that are 329 prohibited for the negotiated key exchange algorithm. The client 330 must check if it possesses a certificate appropriate for any of the 331 methods suggested by the server and is willing to use it for 332 authentication. 334 If these conditions are not met, the client should send a client 335 Certificate message containing no certificates. In this case, the 336 ClientKeyExchange should be sent as described in Section 2 and the 337 CertificateVerify should not be sent. If the server requires client 338 authentication, it may respond with a fatal handshake failure alert. 340 If the client has an appropriate certificate and is willing to use it 341 for authentication, it MUST send that certificate in the client's 342 Certificate message (as per Section 5.6) and prove possession of the 343 private key corresponding to the certified key. The process of 344 determining an appropriate certificate and proving possession is 345 different for each authentication mechanism and described below. 347 NOTE: It is permissible for a server to request (and the client to 348 send) a client certificate of a different type than the server 349 certificate. 351 3.1 ECDSA_sign 353 To use this authentication mechanism, the client MUST possess a 354 certificate containing an ECDSA-capable public key and signed with 355 ECDSA. 357 The client MUST prove possession of the private key corresponding to 358 the certified key by including a signature in the CertificateVerify 359 message as described in Section 5.8. 361 3.2 ECDSA_fixed_ECDH 363 To use this authentication mechanism, the client MUST possess a 364 certificate containing an ECDH-capable public key and that 365 certificate MUST be signed with ECDSA. Furthermore, the client's 366 ECDH key MUST be on the same elliptic curve as the server's long-term 367 (certified) ECDH key. This might limit use of this mechanism to 368 closed environments. In situations where the client has an ECC key 369 on a different curve, it would have to authenticate either using 370 ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for 371 both servers and clients is computationally more efficient than 372 mechanisms providing forward secrecy. 374 When using this authentication mechanism, the client MUST send an 375 empty ClientKeyExchange as described in Section 5.7 and MUST NOT send 376 the CertificateVerify message. The ClientKeyExchange is empty since 377 the client's ECDH public key required by the server to compute the 378 premaster secret is available inside the client's certificate. The 379 client's ability to arrive at the same premaster secret as the server 380 (demonstrated by a successful exchange of Finished messages) proves 381 possession of the private key corresponding to the certified public 382 key and the CertificateVerify message is unnecessary. 384 3.3 RSA_fixed_ECDH 386 This authentication mechanism is identical to ECDSA_fixed_ECDH except 387 the client's certificate MUST be signed with RSA. 389 4. TLS Extensions for ECC 391 Two new TLS extensions --- (i) the Supported Elliptic Curves 392 Extension, and (ii) the Supported Point Formats Extension --- allow a 393 client to negotiate the use of specific curves and point formats 394 (e.g. compressed v/s uncompressed), respectively. These extensions 395 are especially relevant for constrained clients that may only support 396 a limited number of curves or point formats. They follow the general 397 approach outlined in [3]. The client enumerates the curves and point 398 formats it supports by including the appropriate extensions in its 399 ClientHello message. By echoing that extension in its ServerHello, 400 the server agrees to restrict its key selection or encoding to the 401 choices specified by the client. 403 A TLS client that proposes ECC cipher suites in its ClientHello 404 message SHOULD include these extensions. Servers implementing ECC 405 cipher suites MUST support these extensions and negotiate the use of 406 an ECC cipher suite only if they can complete the handshake while 407 limiting themselves to the curves and compression techniques 408 enumerated by the client. This eliminates the possibility that a 409 negotiated ECC handshake will be subsequently aborted due to a 410 client's inability to deal with the server's EC key. 412 These extensions MUST NOT be included if the client does not propose 413 any ECC cipher suites. A client that proposes ECC cipher suites may 414 choose not to include these extension. In this case, the server is 415 free to choose any one of the elliptic curves or point formats listed 416 in Section 5. That section also describes the structure and 417 processing of these extensions in greater detail. 419 5. Data Structures and Computations 421 This section specifies the data structures and computations used by 422 ECC-based key mechanisms specified in Section 2, Section 3 and 423 Section 4. The presentation language used here is the same as that 424 used in TLS [2]. Since this specification extends TLS, these 425 descriptions should be merged with those in the TLS specification and 426 any others that extend TLS. This means that enum types may not 427 specify all possible values and structures with multiple formats 428 chosen with a select() clause may not indicate all possible cases. 430 5.1 Client Hello Extensions 432 When this message is sent: 434 The ECC extensions SHOULD be sent along with any ClientHello message 435 that proposes ECC cipher suites. 437 Meaning of this message: 439 These extensions allow a constrained client to enumerate the elliptic 440 curves and/or point formats it supports. 442 Structure of this message: 444 The general structure of TLS extensions is described in [3] and this 445 specification adds two new types to ExtensionType. 447 enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType; 449 elliptic_curves: Indicates the set of elliptic curves supported by 450 the client. For this extension, the opaque extension_data field 451 contains EllipticCurveList. 452 ec_point_formats: Indicates the set of point formats supported by 453 the client. For this extension, the opaque extension_data field 454 contains ECPointFormatList. 456 enum { 457 sect163k1 (1), sect163r1 (2), sect163r2 (3), 458 sect193r1 (4), sect193r2 (5), sect233k1 (6), 459 sect233r1 (7), sect239k1 (8), sect283k1 (9), 460 sect283r1 (10), sect409k1 (11), sect409r1 (12), 461 sect571k1 (13), sect571r1 (14), secp160k1 (15), 462 secp160r1 (16), secp160r2 (17), secp192k1 (18), 463 secp192r1 (19), secp224k1 (20), secp224r1 (21), 464 secp256k1 (22), secp256r1 (23), secp384r1 (24), 465 secp521r1 (25), reserved (240..247), 466 arbitrary_explicit_prime_curves(253), 467 arbitrary_explicit_char2_curves(254), 468 (255) 469 } NamedCurve; 471 sect163k1, etc: Indicates support of the corresponding named curve 472 specified in SEC 2 [10]. Note that many of these curves are also 473 recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240 474 through 247 are reserved for private use. Values 253 and 254 475 indicate that the client supports arbitrary prime and 476 characteristic-2 curves, respectively (the curve parameters must 477 be encoded explicitly in ECParameters). 479 struct { 480 NamedCurve elliptic_curve_list<1..2^8-1> 481 } EllipticCurveList; 483 Items in elliptic_curve_list are ordered according to the client's 484 preferences (favorite choice first). 486 As an example, a client that only supports secp192r1 (aka NIST P-192) 487 and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would 488 include an elliptic_curves extension with the following octets: 490 00 ?? 00 03 02 13 15 492 A client that supports arbitrary explicit binary polynomial curves 493 would include an extension with the following octets: 495 00 ?? 00 02 01 fe 496 enum { uncompressed (0), ansiX963_compressed (1), 497 ansiX963_hybrid (2), (255) 498 } ECPointFormat; 500 struct { 501 ECPointFormat ec_point_format_list<1..2^8-1> 502 } ECPointFormatList; 504 Three point formats are included in the defintion of ECPointFormat 505 above. The uncompressed point format is the default format that 506 implementations of this document MUST support. The 507 ansix963_compressed format reduces bandwidth by including only the 508 x-coordinate and a single bit of the y-coordinate of the point. The 509 ansix963_hybrid format includes both the full y-coordinate and the 510 compressed y-coordinate to allow flexibility and improve efficiency 511 in some cases. Implementations of this document MAY support the 512 ansix963_compressed and ansix963_hybrid point formats. 514 Items in ec_point_format_list are ordered according to the client's 515 preferences (favorite choice first). 517 A client that only supports the uncompressed point format includes an 518 extension with the following octets: 520 00 ?? 00 02 01 00 522 A client that prefers the use of the ansiX963_compressed format over 523 uncompressed may indicate that preference by including an extension 524 with the following octets: 526 00 ?? 00 03 02 01 00 528 Actions of the sender: 530 A client that proposes ECC cipher suites in its ClientHello appends 531 these extensions (along with any others) enumerating the curves and 532 point formats it supports. 534 Actions of the receiver: 536 A server that receives a ClientHello containing one or both of these 537 extensions MUST use the client's enumerated capabilities to guide its 538 selection of an appropriate cipher suite. One of the proposed ECC 539 cipher suites must be negotiated only if the server can successfully 540 complete the handshake while using the curves and point formats 541 supported by the client. 543 NOTE: A server participating in an ECDHE-ECDSA key exchange may use 544 different curves for (i) the ECDSA key in its certificate, and (ii) 545 the ephemeral ECDH key in the ServerKeyExchange message. The server 546 must consider the "elliptic_curves" extension in selecting both of 547 these curves. 549 If a server does not understand the "elliptic_curves" extension or is 550 unable to complete the ECC handshake while restricting itself to the 551 enumerated curves, it MUST NOT negotiate the use of an ECC cipher 552 suite. Depending on what other cipher suites are proposed by the 553 client and supported by the server, this may result in a fatal 554 handshake failure alert due to the lack of common cipher suites. 556 5.2 Server Hello Extensions 558 When this message is sent: 560 The ServerHello ECC extensions are sent in response to a Client Hello 561 message containing ECC extensions when negotiating an ECC cipher 562 suite. 564 Meaning of this message: 566 These extensions indicate the server's agreement to use only the 567 elliptic curves and point formats supported by the client during the 568 ECC-based key exchange. 570 Structure of this message: 572 The ECC extensions echoed by the server are the same as those in the 573 ClientHello except the "extension_data" field is empty. 575 For example, a server indicates its acceptance of the client's 576 elliptic_curves extension by sending an extension with the following 577 octets: 579 00 ?? 00 00 581 Actions of the sender: 583 A server makes sure that it can complete a proposed ECC key exchange 584 mechanism by restricting itself to the curves/point formats supported 585 by the client before sending these extensions. 587 Actions of the receiver: 589 A client that receives a ServerHello with ECC extensions proceeds 590 with an ECC key exchange assured that it will be able to handle the 591 server's EC key(s). 593 5.3 Server Certificate 595 When this message is sent: 597 This message is sent in all non-anonymous ECC-based key exchange 598 algorithms. 600 Meaning of this message: 602 This message is used to authentically convey the server's static 603 public key to the client. The following table shows the server 604 certificate type appropriate for each key exchange algorithm. ECC 605 public keys must be encoded in certificates as described in 606 Section 5.9. 608 NOTE: The server's Certificate message is capable of carrying a chain 609 of certificates. The restrictions mentioned in Table 3 apply only to 610 the server's certificate (first in the chain). 612 Key Exchange Algorithm Server Certificate Type 613 ---------------------- ----------------------- 615 ECDH_ECDSA Certificate must contain an 616 ECDH-capable public key. It 617 must be signed with ECDSA. 619 ECDHE_ECDSA Certificate must contain an 620 ECDSA-capable public key. It 621 must be signed with ECDSA. 623 ECDH_RSA Certificate must contain an 624 ECDH-capable public key. It 625 must be signed with RSA. 627 ECDHE_RSA Certificate must contain an 628 RSA public key authorized for 629 use in digital signatures. It 630 must be signed with RSA. 632 Table 3: Server certificate types 634 Structure of this message: 636 Identical to the TLS Certificate format. 638 Actions of the sender: 640 The server constructs an appropriate certificate chain and conveys it 641 to the client in the Certificate message. 643 Actions of the receiver: 645 The client validates the certificate chain, extracts the server's 646 public key, and checks that the key type is appropriate for the 647 negotiated key exchange algorithm. 649 5.4 Server Key Exchange 651 When this message is sent: 653 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and 654 ECDH_anon key exchange algorithms. 656 Meaning of this message: 658 This message is used to convey the server's ephemeral ECDH public key 659 (and the corresponding elliptic curve domain parameters) to the 660 client. 662 Structure of this message: 664 enum { explicit_prime (1), explicit_char2 (2), 665 named_curve (3), (255) } ECCurveType; 667 explicit_prime: Indicates the elliptic curve domain parameters are 668 conveyed verbosely, and the underlying finite field is a prime 669 field. 670 explicit_char2: Indicates the elliptic curve domain parameters are 671 conveyed verbosely, and the underlying finite field is a 672 characteristic-2 field. 673 named_curve: Indicates that a named curve is used. This option 674 SHOULD be used when applicable. 676 struct { 677 opaque a <1..2^8-1>; 678 opaque b <1..2^8-1>; 679 } ECCurve; 681 a, b: These parameters specify the coefficients of the elliptic 682 curve. Each value contains the byte string representation of a 683 field element following the conversion routine in Section 4.3.3 of 684 ANSI X9.62 [6]. 686 struct { 687 opaque point <1..2^8-1>; 689 } ECPoint; 691 point: This is the byte string representation of an elliptic curve 692 point following the conversion routine in Section 4.3.6 of ANSI 693 X9.62 [6]. Note that this byte string may represent an elliptic 694 curve point in compressed or uncompressed form. 696 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 698 ec_basis_trinomial: Indicates representation of a characteristic-2 699 field using a trinomial basis. 700 ec_basis_pentanomial: Indicates representation of a characteristic-2 701 field using a pentanomial basis. 703 struct { 704 ECCurveType curve_type; 705 select (curve_type) { 706 case explicit_prime: 707 opaque prime_p <1..2^8-1>; 708 ECCurve curve; 709 ECPoint base; 710 opaque order <1..2^8-1>; 711 opaque cofactor <1..2^8-1>; 712 case explicit_char2: 713 uint16 m; 714 ECBasisType basis; 715 select (basis) { 716 case ec_trinomial: 717 opaque k <1..2^8-1>; 718 case ec_pentanomial: 719 opaque k1 <1..2^8-1>; 720 opaque k2 <1..2^8-1>; 721 opaque k3 <1..2^8-1>; 722 }; 723 ECCurve curve; 724 ECPoint base; 725 opaque order <1..2^8-1>; 726 opaque cofactor <1..2^8-1>; 727 case named_curve: 728 NamedCurve namedcurve; 729 }; 730 } ECParameters; 732 curve_type: This identifies the type of the elliptic curve domain 733 parameters. 735 prime_p: This is the odd prime defining the field Fp. 736 curve: Specifies the coefficients a and b of the elliptic curve E. 737 base: Specifies the base point G on the elliptic curve. 738 order: Specifies the order n of the base point. 739 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) 740 represents the number of points on the elliptic curve E defined 741 over the field Fq. 742 m: This is the degree of the characteristic-2 field F2^m. 743 k: The exponent k for the trinomial basis representation x^m + x^k 744 +1. 745 k1, k2, k3: The exponents for the pentanomial representation x^m + 746 x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). 747 namedcurve: Specifies a recommended set of elliptic curve domain 748 parameters. All enum values of NamedCurve are allowed except for 749 arbitrary_explicit_prime_curves(253) and 750 arbitrary_explicit_char2_curves(254). These two values are only 751 allowed in the ClientHello extension. 753 struct { 754 ECParameters curve_params; 755 ECPoint public; 756 } ServerECDHParams; 758 curve_params: Specifies the elliptic curve domain parameters 759 associated with the ECDH public key. 760 public: The ephemeral ECDH public key. 762 The ServerKeyExchange message is extended as follows. 764 enum { ec_diffie_hellman } KeyExchangeAlgorithm; 766 ec_diffie_hellman: Indicates the ServerKeyExchange message contains 767 an ECDH public key. 769 select (KeyExchangeAlgorithm) { 770 case ec_diffie_hellman: 771 ServerECDHParams params; 772 Signature signed_params; 773 } ServerKeyExchange; 775 params: Specifies the ECDH public key and associated domain 776 parameters. 777 signed_params: A hash of the params, with the signature appropriate 778 to that hash applied. The private key corresponding to the 779 certified public key in the server's Certificate message is used 780 for signing. 782 enum { ecdsa } SignatureAlgorithm; 783 select (SignatureAlgorithm) { 784 case ecdsa: 785 digitally-signed struct { 786 opaque sha_hash[sha_size]; 787 }; 788 } Signature; 790 NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange 791 algorithm and 'anonymous' for ECDH_anon. These cases are defined in 792 TLS [2]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA 793 signatures are generated and verified as described in Section 5.10. 794 As per ANSI X9.62, an ECDSA signature consists of a pair of integers 795 r and s. These integers are both converted into byte strings of the 796 same length as the curve order n using the conversion routine 797 specified in Section 4.3.1 of [6]. The two byte strings are 798 concatenated, and the result is placed in the signature field. 800 Actions of the sender: 802 The server selects elliptic curve domain parameters and an ephemeral 803 ECDH public key corresponding to these parameters according to the 804 ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to 805 the client in the ServerKeyExchange message using the format defined 806 above. 808 Actions of the recipient: 810 The client verifies the signature (when present) and retrieves the 811 server's elliptic curve domain parameters and ephemeral ECDH public 812 key from the ServerKeyExchange message. 814 5.5 Certificate Request 816 When this message is sent: 818 This message is sent when requesting client authentication. 820 Meaning of this message: 822 The server uses this message to suggest acceptable client 823 authentication methods. 825 Structure of this message: 827 The TLS CertificateRequest message is extended as follows. 829 enum { 830 ecdsa_sign(?), rsa_fixed_ecdh(?), 831 ecdsa_fixed_ecdh(?), (255) 832 } ClientCertificateType; 834 ecdsa_sign, etc Indicates that the server would like to use the 835 corresponding client authentication method specified in Section 3. 836 EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and 837 ecdsa_fixed_ecdh have been left as ?. These values will be 838 assigned when this draft progresses to RFC. Earlier versions of 839 this draft used the values 5, 6, and 7 - however these values have 840 been removed since they are used differently by SSL 3.0 [13] and 841 their use by TLS is being deprecated. 843 Actions of the sender: 845 The server decides which client authentication methods it would like 846 to use, and conveys this information to the client using the format 847 defined above. 849 Actions of the receiver: 851 The client determines whether it has an appropriate certificate for 852 use with any of the requested methods, and decides whether or not to 853 proceed with client authentication. 855 5.6 Client Certificate 857 When this message is sent: 859 This message is sent in response to a CertificateRequest when a 860 client has a suitable certificate. 862 Meaning of this message: 864 This message is used to authentically convey the client's static 865 public key to the server. The following table summarizes what client 866 certificate types are appropriate for the ECC-based client 867 authentication mechanisms described in Section 3. ECC public keys 868 must be encoded in certificates as described in Section 5.9. 870 NOTE: The client's Certificate message is capable of carrying a chain 871 of certificates. The restrictions mentioned in Table 4 apply only to 872 the client's certificate (first in the chain). 874 Client 875 Authentication Method Client Certificate Type 876 --------------------- ----------------------- 878 ECDSA_sign Certificate must contain an 879 ECDSA-capable public key and 880 be signed with ECDSA. 882 ECDSA_fixed_ECDH Certificate must contain an 883 ECDH-capable public key on the 884 same elliptic curve as the server's 885 long-term ECDH key. This certificate 886 must be signed with ECDSA. 888 RSA_fixed_ECDH Certificate must contain an 889 ECDH-capable public key on the 890 same elliptic curve as the server's 891 long-term ECDH key. This certificate 892 must be signed with RSA. 894 Table 4: Client certificate types 896 Structure of this message: 898 Identical to the TLS client Certificate format. 900 Actions of the sender: 902 The client constructs an appropriate certificate chain, and conveys 903 it to the server in the Certificate message. 905 Actions of the receiver: 907 The TLS server validates the certificate chain, extracts the client's 908 public key, and checks that the key type is appropriate for the 909 client authentication method. 911 5.7 Client Key Exchange 913 When this message is sent: 915 This message is sent in all key exchange algorithms. If client 916 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 917 message is empty. Otherwise, it contains the client's ephemeral ECDH 918 public key. 920 Meaning of the message: 922 This message is used to convey ephemeral data relating to the key 923 exchange belonging to the client (such as its ephemeral ECDH public 924 key). 926 Structure of this message: 928 The TLS ClientKeyExchange message is extended as follows. 930 enum { yes, no } EphemeralPublicKey; 932 yes, no: Indicates whether or not the client is providing an 933 ephemeral ECDH public key. (In ECC ciphersuites, this is "yes" 934 except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH 935 client authentication mechanism.) 937 struct { 938 select (EphemeralPublicKey) { 939 case yes: ECPoint ecdh_Yc; 940 case no: struct { }; 941 } ecdh_public; 942 } ClientECDiffieHellmanPublic; 944 ecdh_Yc: Contains the client's ephemeral ECDH public key. 946 struct { 947 select (KeyExchangeAlgorithm) { 948 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 949 } exchange_keys; 950 } ClientKeyExchange; 952 Actions of the sender: 954 The client selects an ephemeral ECDH public key corresponding to the 955 parameters it received from the server according to the ECKAS-DH1 956 scheme from IEEE 1363 [5]. It conveys this information to the client 957 in the ClientKeyExchange message using the format defined above. 959 Actions of the recipient: 961 The server retrieves the client's ephemeral ECDH public key from the 962 ClientKeyExchange message and checks that it is on the same elliptic 963 curve as the server's ECDH key. 965 5.8 Certificate Verify 967 When this message is sent: 969 This message is sent when the client sends a client certificate 970 containing a public key usable for digital signatures, e.g. when the 971 client is authenticated using the ECDSA_sign mechanism. 973 Meaning of the message: 975 This message contains a signature that proves possession of the 976 private key corresponding to the public key in the client's 977 Certificate message. 979 Structure of this message: 981 The TLS CertificateVerify message is extended as follows. 983 enum { ecdsa } SignatureAlgorithm; 985 select (SignatureAlgorithm) { 986 case ecdsa: 987 digitally-signed struct { 988 opaque sha_hash[sha_size]; 989 }; 990 } Signature; 992 For the ecdsa case, the signature field in the CertificateVerify 993 message contains an ECDSA signature computed over handshake messages 994 exchanged so far. ECDSA signatures are computed as described in 995 Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a 996 pair of integers r and s. These integers are both converted into 997 byte strings of the same length as the curve order n using the 998 conversion routine specified in Section 4.3.1 of [6]. The two byte 999 strings are concatenated, and the result is placed in the signature 1000 field. 1002 Actions of the sender: 1004 The client computes its signature over all handshake messages sent or 1005 received starting at client hello up to but not including this 1006 message. It uses the private key corresponding to its certified 1007 public key to compute the signature which is conveyed in the format 1008 defined above. 1010 Actions of the receiver: 1012 The server extracts the client's signature from the CertificateVerify 1013 message, and verifies the signature using the public key it received 1014 in the client's Certificate message. 1016 5.9 Elliptic Curve Certificates 1018 X509 certificates containing ECC public keys or signed using ECDSA 1019 MUST comply with [11] or another RFC that replaces or extends it. 1020 Clients SHOULD use the elliptic curve domain parameters recommended 1021 in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. 1023 5.10 ECDH, ECDSA and RSA Computations 1025 All ECDH calculations (including parameter and key generation as well 1026 as the shared secret calculation) MUST be performed according to [5] 1027 using the ECKAS-DH1 scheme with the identity map as key derivation 1028 function, so that the premaster secret is the x-coordinate of the 1029 ECDH shared secret elliptic curve point, i.e. the octet string Z in 1030 IEEE 1363 terminology. 1032 Note that a new extension may be introduced in the future to allow 1033 the use of a different KDF during computation of the premaster 1034 secret. In this event, the new KDF would be used in place of the 1035 process detailed above. This may be desirable, for example, to 1036 support compatibility with the planned NIST key agreement standard. 1038 All ECDSA computations MUST be performed according to ANSI X9.62 [6] 1039 or its successors. Data to be signed/verified is hashed and the 1040 result run directly through the ECDSA algorithm with no additional 1041 hashing. The default hash function is SHA-1 [7] and sha_size (see 1042 Section 5.4 and Section 5.8) is 20. However, an alternative hash 1043 function, such as one of the new SHA hash functions specified in FIPS 1044 180-2 [7], may be used instead if the certificate containing the EC 1045 public key explicitly requires use of another hash function. (The 1046 mechanism for specifying the required hash function has not been 1047 standardized but this provision anticipates such standardization and 1048 obviates the need to update this document in response. Future PKIX 1049 RFCs may choose, for example, to specify the hash function to be used 1050 with a public key in the parameters field of subjectPublicKeyInfo.) 1052 All RSA signatures must be generated and verified according to PKCS#1 1053 [9]. 1055 6. Cipher Suites 1057 The table below defines new ECC cipher suites that use the key 1058 exchange algorithms specified in Section 2. 1060 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1061 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1062 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } 1063 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1064 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1065 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1067 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1068 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1069 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1070 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1071 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1073 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1074 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1075 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1076 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1077 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1079 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1080 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1081 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1082 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1083 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1085 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } 1086 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } 1087 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1088 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1089 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1091 Table 5: TLS ECC cipher suites 1093 Figure 30 1095 The key exchange method, cipher, and hash algorithm for each of these 1096 cipher suites are easily determined by examining the name. Ciphers 1097 other than AES ciphers, and hash algorithms are defined in [2]. AES 1098 ciphers are defined in [14]. 1100 Server implementations SHOULD support all of the following cipher 1101 suites, and client implementations SHOULD support at least one of 1102 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 1103 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 1104 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 1105 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 1107 7. Security Considerations 1109 This document is based on [2], [5], [6] and [14]. The appropriate 1110 security considerations of those documents apply. 1112 One important issue that implementors and users must consider is 1113 elliptic curve selection. Guidance on selecting an appropriate 1114 elliptic curve size is given in Figure 1. 1116 Beyond elliptic curve size, the main issue is elliptic curve 1117 structure. As a general principle, it is more conservative to use 1118 elliptic curves with as little algebraic structure as possible - thus 1119 random curves are more conservative than special curves such as 1120 Koblitz curves, and curves over F_p with p random are more 1121 conservative than curves over F_p with p of a special form (and 1122 curves over F_p with p random might be considered more conservative 1123 than curves over F_2^m as there is no choice between multiple fields 1124 of similar size for characteristic 2). Note, however, that algebraic 1125 structure can also lead to implementation efficiencies and 1126 implementors and users may, therefore, need to balance conservatism 1127 against a need for efficiency. Concrete attacks are known against 1128 only very few special classes of curves, such as supersingular 1129 curves, and these classes are excluded from the ECC standards that 1130 this document references [5], [6]. 1132 Another issue is the potential for catastrophic failures when a 1133 single elliptic curve is widely used. In this case, an attack on the 1134 elliptic curve might result in the compromise of a large number of 1135 keys. Again, this concern may need to be balanced against efficiency 1136 and interoperability improvements associated with widely-used curves. 1137 Substantial additional information on elliptic curve choice can be 1138 found in [4], [5], [6], [8]. 1140 Implementors and users must also consider whether they need forward 1141 secrecy. Forward secrecy refers to the property that session keys 1142 are not compromised if the static, certified keys belonging to the 1143 server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key 1144 exchange algorithms provide forward secrecy protection in the event 1145 of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. 1146 Similarly if the client is providing a static, certified key, 1147 ECDSA_sign client authentication provides forward secrecy protection 1148 in the event of client key compromise, while ECDSA_fixed_ECDH and 1149 RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy 1150 protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, 1151 with ECDSA_sign used for client authentication if necessary. Here 1152 again the security benefits of forward secrecy may need to be 1153 balanced against the improved efficiency offered by other options. 1155 8. Acknowledgments 1157 The authors wish to thank Bill Anderson and Tim Dierks. 1159 9. References 1161 9.1 Normative References 1163 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 1164 Levels", RFC 2119, March 1997. 1166 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1167 RFC 2246, January 1999. 1169 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and 1170 T. Wright, "Transport Layer Security (TLS) Extensions", 1171 Internet-draft draft-ietf-tls-rfc3546bis-00.txt, Nov. 2004. 1173 [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, 1174 . 1176 [5] IEEE, "Standard Specifications for Public Key Cryptography", 1177 IEEE 1363, 2000. 1179 [6] ANSI, "Public Key Cryptography For The Financial Services 1180 Industry: The Elliptic Curve Digital Signature Algorithm 1181 (ECDSA)", ANSI X9.62, 1998. 1183 [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 1185 [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1187 [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1188 1.5", PKCS 1, November 1993. 1190 [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 1191 2000, . 1193 [11] Polk, T., Housley, R. and L. Bassham, "Algorithms and 1194 Identifiers for the Internet X.509 Public Key Infrastructure 1195 Certificate and Certificate Revocation List (CRL) Profile", 1196 RFC 3279, April 2002. 1198 9.2 Informative References 1200 [12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1201 Sizes", Journal of Cryptology 14 (2001) 255-293, 1202 . 1204 [13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol 1205 Version 3.0", November 1996, 1206 . 1208 [14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1209 Transport Layer Security (TLS)", RFC 3268, June 2002. 1211 [15] Hovey, R. and S. Bradner, "The Organizations Involved in the 1212 IETF Standards Process", RFC 2028, BCP 11, October 1996. 1214 Authors' Addresses 1216 Vipul Gupta 1217 Sun Microsystems Laboratories 1218 16 Network Circle 1219 MS UMPK16-160 1220 Menlo Park, CA 94025 1221 USA 1223 Phone: +1 650 786 7551 1224 Email: vipul.gupta@sun.com 1226 Simon Blake-Wilson 1227 Basic Commerce & Industries, Inc. 1228 96 Spandia Ave 1229 Unit 606 1230 Toronto, ON M6G 2T6 1231 Canada 1233 Phone: +1 416 214 5961 1234 Email: sblakewilson@bcisse.com 1236 Bodo Moeller 1237 University of Calgary 1238 Dept of Math & Stats 1239 2500 University Dr NW 1240 Calgary, AB T2N 1N4 1241 CA 1243 Email: bodo@openssl.org 1245 Chris Hawk 1246 Corriente Networks 1248 Email: chris@corriente.net 1249 Nelson Bolyard 1251 Email: nelson@bolyard.com 1253 Intellectual Property Statement 1255 The IETF takes no position regarding the validity or scope of any 1256 Intellectual Property Rights or other rights that might be claimed to 1257 pertain to the implementation or use of the technology described in 1258 this document or the extent to which any license under such rights 1259 might or might not be available; nor does it represent that it has 1260 made any independent effort to identify any such rights. Information 1261 on the procedures with respect to rights in RFC documents can be 1262 found in BCP 78 and BCP 79. 1264 Copies of IPR disclosures made to the IETF Secretariat and any 1265 assurances of licenses to be made available, or the result of an 1266 attempt made to obtain a general license or permission for the use of 1267 such proprietary rights by implementers or users of this 1268 specification can be obtained from the IETF on-line IPR repository at 1269 http://www.ietf.org/ipr. 1271 The IETF invites any interested party to bring to its attention any 1272 copyrights, patents or patent applications, or other proprietary 1273 rights that may cover technology that may be required to implement 1274 this standard. Please address the information to the IETF at 1275 ietf-ipr@ietf.org. 1277 Disclaimer of Validity 1279 This document and the information contained herein are provided on an 1280 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1281 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1282 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1283 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1284 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1285 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1287 Copyright Statement 1289 Copyright (C) The Internet Society (2005). This document is subject 1290 to the rights, licenses and restrictions contained in BCP 78, and 1291 except as set forth therein, the authors retain all their rights. 1293 Acknowledgment 1295 Funding for the RFC Editor function is currently provided by the 1296 Internet Society.