idnits 2.17.00 (12 Aug 2021) /tmp/idnits14301/draft-ietf-tls-ecc-10.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 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1390. ** 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. 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.) ** 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 786 has weird spacing: '...rveType cur...' == Line 799 has weird spacing: '... opaque k <1....' == Line 801 has weird spacing: '... opaque k1 <1...' == Line 802 has weird spacing: '... opaque k2 <1...' == Line 803 has weird spacing: '... opaque k3 <1...' == (2 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.) -- The document date (May 31, 2005) is 6198 days in the past. Is this intentional? 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 218 == Unused Reference: '12' is defined on line 1313, 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. '15') (Obsoleted by RFC 5246) Summary: 6 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: December 2, 2005 S. Blake-Wilson 5 BCI 6 B. Moeller 7 University of Calgary 8 C. Hawk 9 Corriente Networks 10 N. Bolyard 11 May 31, 2005 13 ECC Cipher Suites for TLS 14 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 2, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document describes new key exchange algorithms based on Elliptic 48 Curve Cryptography (ECC) for the TLS (Transport Layer Security) 49 protocol. In particular, it specifies the use of Elliptic Curve 50 Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of 51 Elliptic Curve Digital Signature Algorithm (ECDSA) as a new 52 authentication mechanism. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [1]. 58 Please send comments on this document to the TLS mailing list. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5 64 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7 68 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9 70 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 72 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 73 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 74 5. Data Structures and Computations . . . . . . . . . . . . . . 12 75 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 76 5.2 Server Hello Extension . . . . . . . . . . . . . . . . . . 15 77 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16 78 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18 79 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22 80 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23 81 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 24 82 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 25 83 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 26 84 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 26 85 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 28 86 7. Security Considerations . . . . . . . . . . . . . . . . . . 30 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 89 9.1 Normative References . . . . . . . . . . . . . . . . . . . 32 90 9.2 Informative References . . . . . . . . . . . . . . . . . . 32 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 92 Intellectual Property and Copyright Statements . . . . . . . 35 94 1. Introduction 96 Elliptic Curve Cryptography (ECC) is emerging as an attractive 97 public-key cryptosystem for mobile/wireless environments. Compared 98 to currently prevalent cryptosystems such as RSA, ECC offers 99 equivalent security with smaller key sizes. This is illustrated in 100 the following table, based on [13], which gives approximate 101 comparable key sizes for symmetric- and asymmetric-key cryptosystems 102 based on the best-known algorithms for attacking them. 104 Symmetric | ECC | DH/DSA/RSA 105 -------------+---------+------------ 106 80 | 163 | 1024 107 112 | 233 | 2048 108 128 | 283 | 3072 109 192 | 409 | 7680 110 256 | 571 | 15360 112 Table 1: Comparable key sizes (in bits) 114 Smaller key sizes result in power, bandwidth and computational 115 savings that make ECC especially attractive for constrained 116 environments. 118 This document describes additions to TLS to support ECC. In 119 particular, it defines 121 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement 122 scheme with long-term or ephemeral keys to establish the TLS 123 premaster secret, and 125 o the use of fixed-ECDH certificates and ECDSA for authentication of 126 TLS peers. 128 The remainder of this document is organized as follows. Section 2 129 provides an overview of ECC-based key exchange algorithms for TLS. 130 Section 3 describes the use of ECC certificates for client 131 authentication. TLS extensions that allow a client to negotiate the 132 use of specific curves and point formats are presented in Section 4. 133 Section 5 specifies various data structures needed for an ECC-based 134 handshake, their encoding in TLS messages and the processing of those 135 messages. Section 6 defines new ECC-based cipher suites and 136 identifies a small subset of these as recommended for all 137 implementations of this specification. Section 7 and Section 8 138 mention security considerations and acknowledgments, respectively. 139 This is followed by a list of references cited in this document, the 140 authors' contact information, and statements on intellectual property 141 rights and copyrights. 143 Implementation of this specification requires familiarity with TLS 144 [2], TLS extensions [3] and ECC [4][5][6][8]. 146 2. Key Exchange Algorithms 148 This document introduces five new ECC-based key exchange algorithms 149 for TLS. All of them use ECDH to compute the TLS premaster secret 150 and differ only in the lifetime of ECDH keys (long-term or ephemeral) 151 and the mechanism (if any) used to authenticate them. The derivation 152 of the TLS master secret from the premaster secret and the subsequent 153 generation of bulk encryption/MAC keys and initialization vectors is 154 independent of the key exchange algorithm and not impacted by the 155 introduction of ECC. 157 The table below summarizes the new key exchange algorithms which 158 mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]), 159 respectively. 161 Key 162 Exchange 163 Algorithm Description 164 --------- ----------- 166 ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. 168 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. 170 ECDH_RSA Fixed ECDH with RSA-signed certificates. 172 ECDHE_RSA Ephemeral ECDH with RSA signatures. 174 ECDH_anon Anonymous ECDH, no signatures. 176 Table 2: ECC key exchange algorithms 178 The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward 179 secrecy. With ECDHE_RSA, a server can reuse its existing RSA 180 certificate and easily comply with a constrained client's elliptic 181 curve preferences (see Section 4). However, the computational cost 182 incurred by a server is higher for ECDHE_RSA than for the traditional 183 RSA key exchange which does not provide forward secrecy. 185 The ECDH_RSA mechanism requires a server to acquire an ECC 186 certificate but the certificate issuer can still use an existing RSA 187 key for signing. This eliminates the need to update the trusted key 188 store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for 189 the server as well as the certification authority and is best suited 190 for constrained devices unable to support RSA. 192 The anonymous key exchange algorithm does not provide authentication 193 of the server or the client. Like other anonymous TLS key exchanges, 194 it is subject to man-in-the-middle attacks. Implementations of this 195 algorithm SHOULD provide authentication by other means. 197 Note that there is no structural difference between ECDH and ECDSA 198 keys. A certificate issuer may use X509.v3 keyUsage and 199 extendedKeyUsage extensions to restrict the use of an ECC public key 200 to certain computations. This document refers to an ECC key as ECDH- 201 capable if its use in ECDH is permitted. ECDSA-capable is defined 202 similarly. 204 Client Server 205 ------ ------ 207 ClientHello --------> 208 ServerHello 209 Certificate* 210 ServerKeyExchange* 211 CertificateRequest*+ 212 <-------- ServerHelloDone 213 Certificate*+ 214 ClientKeyExchange 215 CertificateVerify*+ 216 [ChangeCipherSpec] 217 Finished --------> 218 [ChangeCipherSpec] 219 <-------- Finished 221 Application Data <-------> Application Data 223 * message is not sent under some conditions 224 + message is not sent unless client authentication 225 is desired 227 Figure 1: Message flow in a full TLS handshake 229 Figure 1 shows all messages involved in the TLS key establishment 230 protocol (aka full handshake). The addition of ECC has direct impact 231 only on the ClientHello, the ServerHello, the server's Certificate 232 message, the ServerKeyExchange, the ClientKeyExchange, the 233 CertificateRequest, the client's Certificate message, and the 234 CertificateVerify. Next, we describe each ECC key exchange algorithm 235 in greater detail in terms of the content and processing of these 236 messages. For ease of exposition, we defer discussion of client 237 authentication and associated messages (identified with a + in 238 Figure 1) until Section 3 and of the optional ECC-specific extensions 239 (which impact the Hello messages) until Section 4. 241 2.1 ECDH_ECDSA 243 In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable 244 public key and be signed with ECDSA. 246 A ServerKeyExchange MUST NOT be sent (the server's certificate 247 contains all the necessary keying information required by the client 248 to arrive at the premaster secret). 250 The client generates an ECDH key pair on the same curve as the 251 server's long-term public key and send its public key in the 252 ClientKeyExchange message (except when using client authentication 253 algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the 254 modifications from section Section 3.2 or Section 3.3 apply). 256 Both client and server perform an ECDH operation and use the 257 resultant shared secret as the premaster secret. All ECDH 258 calculations are performed as specified in Section 5.10 260 2.2 ECDHE_ECDSA 262 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- 263 capable public key and be signed with ECDSA. 265 The server sends its ephemeral ECDH public key and a specification of 266 the corresponding curve in the ServerKeyExchange message. These 267 parameters MUST be signed with ECDSA using the private key 268 corresponding to the public key in the server's Certificate. 270 The client generates an ECDH key pair on the same curve as the 271 server's ephemeral ECDH key and send its public key in the 272 ClientKeyExchange message. 274 Both client and server perform an ECDH operation (Section 5.10) and 275 use the resultant shared secret as the premaster secret. 277 2.3 ECDH_RSA 279 This key exchange algorithm is the same as ECDH_ECDSA except the 280 server's certificate MUST be signed with RSA rather than ECDSA. 282 2.4 ECDHE_RSA 284 This key exchange algorithm is the same as ECDHE_ECDSA except the 285 server's certificate MUST contain an RSA public key authorized for 286 signing and the signature in the ServerKeyExchange message must be 287 computed with the corresponding RSA private key. The server 288 certificate MUST be signed with RSA. 290 2.5 ECDH_anon 292 In ECDH_anon, the server's Certificate, the CertificateRequest, the 293 client's Certificate, and the CertificateVerify messages MUST NOT be 294 sent. 296 The server MUST send an ephemeral ECDH public key and a specification 297 of the corresponding curve in the ServerKeyExchange message. These 298 parameters MUST NOT be signed. 300 The client generates an ECDH key pair on the same curve as the 301 server's ephemeral ECDH key and send its public key in the 302 ClientKeyExchange message. 304 Both client and server perform an ECDH operation and use the 305 resultant shared secret as the premaster secret. All ECDH 306 calculations are performed as specified in Section 5.10. 308 Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA 309 key exchange algorithms require the server's certificate to be signed 310 with a particular signature scheme, this specification (following the 311 similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2]) does not 312 impose restrictions on signature schemes used elsewhere in the 313 certificate chain. (Often such restrictions will be useful, and it 314 is expected that this will be taken into account in certification 315 authorities' signing practices. However, such restrictions are not 316 strictly required in general: Even if it is beyond the capabilities 317 of a client to completely validate a given chain, the client may be 318 able to validate the server's certificate by relying on a trust 319 anchor that appears as one of the intermediate certificates in the 320 chain.) 322 3. Client Authentication 324 This document defines three new client authentication mechanisms 325 named after the type of client certificate involved: ECDSA_sign, 326 ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is 327 usable with any of the non-anonymous ECC key exchange algorithms 328 described in Section 2 as well as other non-anonymous (non-ECC) key 329 exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and 330 RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. 331 Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the 332 use of a long-term ECDH client key would jeopardize the forward 333 secrecy property of these algorithms. 335 The server can request ECC-based client authentication by including 336 one or more of these certificate types in its CertificateRequest 337 message. The server must not include any certificate types that are 338 prohibited for the negotiated key exchange algorithm. The client 339 must check if it possesses a certificate appropriate for any of the 340 methods suggested by the server and is willing to use it for 341 authentication. 343 If these conditions are not met, the client should send a client 344 Certificate message containing no certificates. In this case, the 345 ClientKeyExchange should be sent as described in Section 2 and the 346 CertificateVerify should not be sent. If the server requires client 347 authentication, it may respond with a fatal handshake failure alert. 349 If the client has an appropriate certificate and is willing to use it 350 for authentication, it must send that certificate in the client's 351 Certificate message (as per Section 5.6) and prove possession of the 352 private key corresponding to the certified key. The process of 353 determining an appropriate certificate and proving possession is 354 different for each authentication mechanism and described below. 356 NOTE: It is permissible for a server to request (and the client to 357 send) a client certificate of a different type than the server 358 certificate. 360 3.1 ECDSA_sign 362 To use this authentication mechanism, the client MUST possess a 363 certificate containing an ECDSA-capable public key and signed with 364 ECDSA. 366 The client proves possession of the private key corresponding to the 367 certified key by including a signature in the CertificateVerify 368 message as described in Section 5.8. 370 3.2 ECDSA_fixed_ECDH 372 To use this authentication mechanism, the client MUST possess a 373 certificate containing an ECDH-capable public key and that 374 certificate MUST be signed with ECDSA. Furthermore, the client's 375 ECDH key MUST be on the same elliptic curve as the server's long-term 376 (certified) ECDH key. This might limit use of this mechanism to 377 closed environments. In situations where the client has an ECC key 378 on a different curve, it would have to authenticate either using 379 ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for 380 both servers and clients is computationally more efficient than 381 mechanisms providing forward secrecy. 383 When using this authentication mechanism, the client MUST send an 384 empty ClientKeyExchange as described in Section 5.7 and MUST NOT send 385 the CertificateVerify message. The ClientKeyExchange is empty since 386 the client's ECDH public key required by the server to compute the 387 premaster secret is available inside the client's certificate. The 388 client's ability to arrive at the same premaster secret as the server 389 (demonstrated by a successful exchange of Finished messages) proves 390 possession of the private key corresponding to the certified public 391 key and the CertificateVerify message is unnecessary. 393 3.3 RSA_fixed_ECDH 395 This authentication mechanism is identical to ECDSA_fixed_ECDH except 396 the client's certificate MUST be signed with RSA. 398 Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH 399 client authentication mechanisms require the clients's certificate to 400 be signed with a particular signature scheme, this specification does 401 not impose restrictions on signature schemes used elsewhere in the 402 certificate chain. (Often such restrictions will be useful, and it 403 is expected that this will be taken into account in certification 404 authorities' signing practices. However, such restrictions are not 405 strictly required in general: Even if it is beyond the capabilities 406 of a server to completely validate a given chain, the server may be 407 able to validate the clients certificate by relying on a trust anchor 408 that appears as one of the intermediate certificates in the chain.) 410 4. TLS Extensions for ECC 412 Two new TLS extensions are defined in this specification: (i) the 413 Supported Elliptic Curves Extension, and (ii) the Supported Point 414 Formats Extension. These allow negotiating the use of specific 415 curves and point formats (e.g. compressed vs. uncompressed), 416 respectively, during a handshake starting a new session. These 417 extensions are especially relevant for constrained clients that may 418 only support a limited number of curves or point formats. They 419 follow the general approach outlined in [3]; message details are 420 specified in Section 5. The client enumerates the curves it supports 421 and the point formats it can parse by including the appropriate 422 extensions in its ClientHello message. The server similarly 423 enumerates the point formats it can parse by including an extension 424 in its ServerHello message. 426 A TLS client that proposes ECC cipher suites in its ClientHello 427 message SHOULD include these extensions. Servers implementing ECC 428 cipher suites MUST support these extensions, and when a client uses 429 these extensions, servers MUST NOT negotiate the use of an ECC cipher 430 suite unless they can complete the handshake while respecting the 431 choice of curves and compression techniques specified by the client. 432 This eliminates the possibility that a negotiated ECC handshake will 433 be subsequently aborted due to a client's inability to deal with the 434 server's EC key. 436 These extensions MUST NOT be included if the client does not propose 437 any ECC cipher suites. A client that proposes ECC cipher suites may 438 choose not to include these extension. In this case, the server is 439 free to choose any one of the elliptic curves or point formats listed 440 in Section 5. That section also describes the structure and 441 processing of these extensions in greater detail. 443 In the case of session resumption, the server simply ignores the 444 Supported Elliptic Curves Extension and the Supported Point Formats 445 Extension as appearing in the current ClientHello message. These 446 extensions only play a role during handshakes negotiating a new 447 session. 449 5. Data Structures and Computations 451 This section specifies the data structures and computations used by 452 ECC-based key mechanisms specified in Section 2, Section 3 and 453 Section 4. The presentation language used here is the same as that 454 used in TLS [2]. Since this specification extends TLS, these 455 descriptions should be merged with those in the TLS specification and 456 any others that extend TLS. This means that enum types may not 457 specify all possible values and structures with multiple formats 458 chosen with a select() clause may not indicate all possible cases. 460 5.1 Client Hello Extensions 462 This section specifies two TLS extensions that can be included with 463 the ClientHello message as described in [3], the Supported Elliptic 464 Curves Extension and the Supported Point Formats Extension. 466 When these extensions are sent: 468 The extensions SHOULD be sent along with any ClientHello message that 469 proposes ECC cipher suites. 471 Meaning of these extensions: 473 These extensions allow a client to enumerate the elliptic curves it 474 supports and/or the point formats it can parse. 476 Structure of these extensions: 478 The general structure of TLS extensions is described in [3] and this 479 specification adds two new types to ExtensionType. 481 enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType; 483 [[ EDITOR: The values used for elliptic_curves and ec_point_formats 484 have been left as ??. These values will be assigned when this draft 485 progresses to RFC. (The examples below will have to be changed 486 accordingly.) ]] 488 elliptic_curves (Supported Elliptic Curves Extension): Indicates the 489 set of elliptic curves supported by the client. For this 490 extension, the opaque extension_data field contains 491 EllipticCurveList. 493 ec_point_formats (Supported Point Formats Extension): Indicates the 494 set of point formats that the client can parse. For this 495 extension, the opaque extension_data field contains 496 ECPointFormatList. 498 enum { 499 sect163k1 (1), sect163r1 (2), sect163r2 (3), 500 sect193r1 (4), sect193r2 (5), sect233k1 (6), 501 sect233r1 (7), sect239k1 (8), sect283k1 (9), 502 sect283r1 (10), sect409k1 (11), sect409r1 (12), 503 sect571k1 (13), sect571r1 (14), secp160k1 (15), 504 secp160r1 (16), secp160r2 (17), secp192k1 (18), 505 secp192r1 (19), secp224k1 (20), secp224r1 (21), 506 secp256k1 (22), secp256r1 (23), secp384r1 (24), 507 secp521r1 (25), reserved (240..247), 508 arbitrary_explicit_prime_curves(253), 509 arbitrary_explicit_char2_curves(254), 510 (255) 511 } NamedCurve; 513 sect163k1, etc: Indicates support of the corresponding named curve 514 specified in SEC 2 [10]. Note that many of these curves are also 515 recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240 516 through 247 are reserved for private use. Values 253 and 254 517 indicate that the client supports arbitrary prime and 518 characteristic-2 curves, respectively (the curve parameters must 519 be encoded explicitly in ECParameters). 521 struct { 522 NamedCurve elliptic_curve_list<1..2^8-1> 523 } EllipticCurveList; 525 Items in elliptic_curve_list are ordered according to the client's 526 preferences (favorite choice first). 528 As an example, a client that only supports secp192r1 (aka NIST P-192; 529 value 19 = 0x13) and secp224r1 (aka NIST P-224; value 21 = 0x15) and 530 prefers to use secp192r1 would include a TLS extension consisting of 531 the following octets: 533 00 ?? 00 03 02 13 15 535 A client that supports arbitrary explicit characteristic-2 curves 536 (value 254 = 0xFE) would include an extension consisting of the 537 following octets: 539 00 ?? 00 02 01 FE 541 enum { uncompressed (0), ansiX962_compressed_prime (1), 542 ansiX962_compressed_char2 (2), reserved (3 .. 255) 543 } ECPointFormat; 545 struct { 546 ECPointFormat ec_point_format_list<1..2^8-1> 547 } ECPointFormatList; 549 Three point formats are included in the definition of ECPointFormat 550 above. The uncompressed point format is the default format in that 551 implementations of this document MUST support it for all of their 552 supported curves. Compressed point formats reduce bandwidth by 553 including only the x-coordinate and a single bit of the y-coordinate 554 of the point. Implementations of this document MAY support the 555 ansiX962_compressed_prime and ansiX962_compressed_char2 formats, 556 where the former applies only to prime curves and the latter applies 557 only to characteristic-2 curves. (All formats are described in [6].) 558 Values 248 through 255 are reserved for private use. 560 Items in ec_point_format_list are ordered according to the client's 561 preferences (favorite choice first). 563 A client that can parse only the uncompressed point format (value 0) 564 includes an extension consisting of the following octets: 566 00 ?? 00 02 01 00 568 A client that in the case of prime fields prefers the compressed 569 format (ansiX962_compressed_prime, value 1) over the uncompressed 570 format (value 0), but in the case of characteristic-2 fields prefers 571 the uncompressed format (value 0) over the compressed format 572 (ansiX962_compressed_char2, value 2), may indicate these preferences 573 by including an extension consisting of the following octets: 575 00 ?? 00 04 03 01 00 02 577 Actions of the sender: 579 A client that proposes ECC cipher suites in its ClientHello message 580 appends these extensions (along with any others), enumerating the 581 curves it supports and the point formats it can parse. Clients 582 SHOULD send both the Supported Elliptic Curves Extension and the 583 Supported Point Formats Extension. If the Supported Point Formats 584 Extension is indeed sent, it MUST contain the value 0 (uncompressed) 585 as one of the items in the list of point formats. 587 Actions of the receiver: 589 A server that receives a ClientHello containing one or both of these 590 extensions MUST use the client's enumerated capabilities to guide its 591 selection of an appropriate cipher suite. One of the proposed ECC 592 cipher suites must be negotiated only if the server can successfully 593 complete the handshake while using the curves and point formats 594 supported by the client (cf. Section 5.3 and Section 5.4). 596 NOTE: A server participating in an ECDHE-ECDSA key exchange may use 597 different curves for (i) the ECDSA key in its certificate, and (ii) 598 the ephemeral ECDH key in the ServerKeyExchange message. The server 599 must consider the "elliptic_curves" extension in selecting both of 600 these curves. 602 If a server does not understand the "elliptic_curves" extension or is 603 unable to complete the ECC handshake while restricting itself to the 604 enumerated curves, it MUST NOT negotiate the use of an ECC cipher 605 suite. Depending on what other cipher suites are proposed by the 606 client and supported by the server, this may result in a fatal 607 handshake failure alert due to the lack of common cipher suites. 609 5.2 Server Hello Extension 611 This section specifies a TLS extension that can be included with the 612 ServerHello message as described in [3], the Supported Point Formats 613 Extension. 615 When this extension is sent: 617 The Supported Point Formats Extension is included in a ServerHello 618 message in response to a ClientHello message containing the Supported 619 Point Formats Extension when negotiating an ECC cipher suite. 621 Meaning of this extensions: 623 This extension allows a server to enumerate the point formats it can 624 parse (for the curve that will appear in its ServerKeyExchange 625 message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key 626 exchange algorithm, or for the curve that is used in the server's 627 public key that will appear in its Certificate message when using the 628 ECDH_ECDSA or ECDH_RSA key exchange algorithm). 630 Structure of this extension: 632 The server's Supported Point Formats Extension has the same structure 633 as the client's Supported Point Formats Extension. Items in 634 elliptic_curve_list here are ordered according to the server's 635 preference (favorite choice first). Note that the server may include 636 items that were not found in the client's list (e.g., the server may 637 prefer to receive points in compressed format even when a client 638 cannot parse this format: the same client may nevertheless be capable 639 to output points in compressed format). 641 Actions of the sender: 643 A server that selects an ECC cipher suite in response to a 644 ClientHello message including a Supported Point Formats Extension 645 appends this extension (along with others) to its ServerHello 646 message, enumerating the point formats it can parse. The Supported 647 Point Formats Extension, when used, MUST contain the value 0 648 (uncompressed) as one of the items in the list of point formats. 650 Actions of the receiver: 652 A client that receives a ServerHello message containing a Supported 653 Point Formats Extension MUST respect the server's choice of point 654 formats during the handshake (cf. Section 5.6 and Section 5.7). If 655 no Supported Point Formats Extension is received with the 656 ServerHello, this is equivalent to an extension allowing only the 657 uncompressed point format. 659 5.3 Server Certificate 661 When this message is sent: 663 This message is sent in all non-anonymous ECC-based key exchange 664 algorithms. 666 Meaning of this message: 668 This message is used to authentically convey the server's static 669 public key to the client. The following table shows the server 670 certificate type appropriate for each key exchange algorithm. ECC 671 public keys must be encoded in certificates as described in 672 Section 5.9. 674 NOTE: The server's Certificate message is capable of carrying a chain 675 of certificates. The restrictions mentioned in Table 3 apply only to 676 the server's certificate (first in the chain). 678 Key Exchange Algorithm Server Certificate Type 679 ---------------------- ----------------------- 681 ECDH_ECDSA Certificate must contain an 682 ECDH-capable public key. It 683 must be signed with ECDSA. 685 ECDHE_ECDSA Certificate must contain an 686 ECDSA-capable public key. It 687 must be signed with ECDSA. 689 ECDH_RSA Certificate must contain an 690 ECDH-capable public key. It 691 must be signed with RSA. 693 ECDHE_RSA Certificate must contain an 694 RSA public key authorized for 695 use in digital signatures. It 696 must be signed with RSA. 698 Table 3: Server certificate types 700 Structure of this message: 702 Identical to the TLS Certificate format. 704 Actions of the sender: 706 The server constructs an appropriate certificate chain and conveys it 707 to the client in the Certificate message. If the client has used a 708 Supported Elliptic Curves Extension, the public key in the server's 709 certificate MUST respect the client's choice of elliptic curves; in 710 particular, the public key MUST employ a named curve (not the same 711 curve as an explicit curve) unless the client has indicated support 712 for explicit curves of the appropriate type. If the client has used 713 a Supported Point Formats Extension, both the server's public key 714 point and (in the case of an explicit curve) the curve's base point 715 MUST respect the client's choice of point formats. (A server that 716 cannot satisfy these requirements must not choose an ECC cipher suite 717 in its ServerHello message.) 719 Actions of the receiver: 721 The client validates the certificate chain, extracts the server's 722 public key, and checks that the key type is appropriate for the 723 negotiated key exchange algorithm. 725 5.4 Server Key Exchange 727 When this message is sent: 729 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and 730 ECDH_anon key exchange algorithms. 732 Meaning of this message: 734 This message is used to convey the server's ephemeral ECDH public key 735 (and the corresponding elliptic curve domain parameters) to the 736 client. 738 Structure of this message: 740 enum { explicit_prime (1), explicit_char2 (2), 741 named_curve (3), reserved(4 .. 255) } ECCurveType; 743 explicit_prime: Indicates the elliptic curve domain parameters are 744 conveyed verbosely, and the underlying finite field is a prime 745 field. 747 explicit_char2: Indicates the elliptic curve domain parameters are 748 conveyed verbosely, and the underlying finite field is a 749 characteristic-2 field. 751 named_curve: Indicates that a named curve is used. This option 752 SHOULD be used when applicable. 754 Values 248 through 255 are reserved for private use. 756 struct { 757 opaque a <1..2^8-1>; 758 opaque b <1..2^8-1>; 759 } ECCurve; 761 a, b: These parameters specify the coefficients of the elliptic 762 curve. Each value contains the byte string representation of a 763 field element following the conversion routine in Section 4.3.3 of 764 ANSI X9.62 [6]. 766 struct { 767 opaque point <1..2^8-1>; 768 } ECPoint; 770 point: This is the byte string representation of an elliptic curve 771 point following the conversion routine in Section 4.3.6 of ANSI 772 X9.62 [6]. This byte string may represent an elliptic curve point 773 in uncompressed, or compressed format; it MUST conform to what the 774 client has requested through a Supported Point Formats Extension 775 if this extension was used. 777 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 779 ec_basis_trinomial: Indicates representation of a characteristic-2 780 field using a trinomial basis. 782 ec_basis_pentanomial: Indicates representation of a characteristic-2 783 field using a pentanomial basis. 785 struct { 786 ECCurveType curve_type; 787 select (curve_type) { 788 case explicit_prime: 789 opaque prime_p <1..2^8-1>; 790 ECCurve curve; 791 ECPoint base; 792 opaque order <1..2^8-1>; 793 opaque cofactor <1..2^8-1>; 794 case explicit_char2: 795 uint16 m; 796 ECBasisType basis; 797 select (basis) { 798 case ec_trinomial: 799 opaque k <1..2^8-1>; 800 case ec_pentanomial: 801 opaque k1 <1..2^8-1>; 802 opaque k2 <1..2^8-1>; 803 opaque k3 <1..2^8-1>; 804 }; 805 ECCurve curve; 806 ECPoint base; 807 opaque order <1..2^8-1>; 808 opaque cofactor <1..2^8-1>; 809 case named_curve: 810 NamedCurve namedcurve; 811 }; 812 } ECParameters; 814 curve_type: This identifies the type of the elliptic curve domain 815 parameters. 817 prime_p: This is the odd prime defining the field Fp. 819 curve: Specifies the coefficients a and b of the elliptic curve E. 821 base: Specifies the base point G on the elliptic curve. 823 order: Specifies the order n of the base point. 825 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) 826 represents the number of points on the elliptic curve E defined 827 over the field Fq (either Fp or F2^m). 829 m: This is the degree of the characteristic-2 field F2^m. 831 k: The exponent k for the trinomial basis representation x^m + x^k 832 +1. 834 k1, k2, k3: The exponents for the pentanomial representation x^m + 835 x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). 837 namedcurve: Specifies a recommended set of elliptic curve domain 838 parameters. All enum values of NamedCurve are allowed except for 839 arbitrary_explicit_prime_curves(253) and 840 arbitrary_explicit_char2_curves(254). These two values are only 841 allowed in the ClientHello extension. 843 struct { 844 ECParameters curve_params; 845 ECPoint public; 846 } ServerECDHParams; 848 curve_params: Specifies the elliptic curve domain parameters 849 associated with the ECDH public key. 851 public: The ephemeral ECDH public key. 853 The ServerKeyExchange message is extended as follows. 855 enum { ec_diffie_hellman } KeyExchangeAlgorithm; 857 ec_diffie_hellman: Indicates the ServerKeyExchange message contains 858 an ECDH public key. 860 select (KeyExchangeAlgorithm) { 861 case ec_diffie_hellman: 862 ServerECDHParams params; 863 Signature signed_params; 864 } ServerKeyExchange; 866 params: Specifies the ECDH public key and associated domain 867 parameters. 869 signed_params: A hash of the params, with the signature appropriate 870 to that hash applied. The private key corresponding to the 871 certified public key in the server's Certificate message is used 872 for signing. 874 enum { ecdsa } SignatureAlgorithm; 876 select (SignatureAlgorithm) { 877 case ecdsa: 878 digitally-signed struct { 879 opaque sha_hash[sha_size]; 880 }; 881 } Signature; 883 NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange 884 algorithm and "anonymous" for ECDH_anon. These cases are defined in 885 TLS [2]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA 886 signatures are generated and verified as described in Section 5.10. 887 As per ANSI X9.62, an ECDSA signature consists of a pair of integers 888 r and s. These integers are both converted into byte strings of the 889 same length as the curve order n using the conversion routine 890 specified in Section 4.3.1 of [6]. The two byte strings are 891 concatenated, and the result is placed in the signature field. 893 Actions of the sender: 895 The server selects elliptic curve domain parameters and an ephemeral 896 ECDH public key corresponding to these parameters according to the 897 ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to 898 the client in the ServerKeyExchange message using the format defined 899 above. 901 Actions of the recipient: 903 The client verifies the signature (when present) and retrieves the 904 server's elliptic curve domain parameters and ephemeral ECDH public 905 key from the ServerKeyExchange message. 907 5.5 Certificate Request 909 When this message is sent: 911 This message is sent when requesting client authentication. 913 Meaning of this message: 915 The server uses this message to suggest acceptable client 916 authentication methods. 918 Structure of this message: 920 The TLS CertificateRequest message is extended as follows. 922 enum { 923 ecdsa_sign(??), rsa_fixed_ecdh(??), 924 ecdsa_fixed_ecdh(??), (255) 925 } ClientCertificateType; 927 ecdsa_sign, etc Indicates that the server would like to use the 928 corresponding client authentication method specified in Section 3. 930 [[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and 931 ecdsa_fixed_ecdh have been left as ??. These values will be 932 assigned when this draft progresses to RFC. Earlier versions of 933 this draft used the values 5, 6, and 7 - however these values have 934 been removed since they are used differently by SSL 3.0 [14] and 935 their use by TLS is being deprecated. ]] 937 Actions of the sender: 939 The server decides which client authentication methods it would like 940 to use, and conveys this information to the client using the format 941 defined above. 943 Actions of the receiver: 945 The client determines whether it has a suitable certificate for use 946 with any of the requested methods, and decides whether or not to 947 proceed with client authentication. 949 5.6 Client Certificate 951 When this message is sent: 953 This message is sent in response to a CertificateRequest when a 954 client has a suitable certificate and has decided to proceed with 955 client authentication. (Note that if the server has used a Supported 956 Point Formats Extension, a certificate can only be considered 957 suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and 958 ECDSA_fixed_ECDH authentication methods if the public key point 959 specified in it respects the server's choice of point formats. If no 960 Supported Point Formats Extension has been used, a certificate can 961 only be considered suitable for use with these authentication methods 962 if the point is represented in uncompressed point format.) 964 Meaning of this message: 966 This message is used to authentically convey the client's static 967 public key to the server. The following table summarizes what client 968 certificate types are appropriate for the ECC-based client 969 authentication mechanisms described in Section 3. ECC public keys 970 must be encoded in certificates as described in Section 5.9. 972 NOTE: The client's Certificate message is capable of carrying a chain 973 of certificates. The restrictions mentioned in Table 4 apply only to 974 the client's certificate (first in the chain). 976 Client 977 Authentication Method Client Certificate Type 978 --------------------- ----------------------- 980 ECDSA_sign Certificate MUST contain an 981 ECDSA-capable public key and 982 be signed with ECDSA. 984 ECDSA_fixed_ECDH Certificate MUST contain an 985 ECDH-capable public key on the 986 same elliptic curve as the server's 987 long-term ECDH key. This certificate 988 MUST be signed with ECDSA. 990 RSA_fixed_ECDH Certificate MUST contain an 991 ECDH-capable public key on the 992 same elliptic curve as the server's 993 long-term ECDH key. This certificate 994 MUST be signed with RSA. 996 Table 4: Client certificate types 998 Structure of this message: 1000 Identical to the TLS client Certificate format. 1002 Actions of the sender: 1004 The client constructs an appropriate certificate chain, and conveys 1005 it to the server in the Certificate message. 1007 Actions of the receiver: 1009 The TLS server validates the certificate chain, extracts the client's 1010 public key, and checks that the key type is appropriate for the 1011 client authentication method. 1013 5.7 Client Key Exchange 1015 When this message is sent: 1017 This message is sent in all key exchange algorithms. If client 1018 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 1019 message is empty. Otherwise, it contains the client's ephemeral ECDH 1020 public key. 1022 Meaning of the message: 1024 This message is used to convey ephemeral data relating to the key 1025 exchange belonging to the client (such as its ephemeral ECDH public 1026 key). 1028 Structure of this message: 1030 The TLS ClientKeyExchange message is extended as follows. 1032 enum { implicit, explicit } PublicValueEncoding; 1034 implicit, explicit: For ECC cipher suites, this indicates whether 1035 the client's ECDH public key is in the client's certificate 1036 ("implicit") or is provided, as an ephemeral ECDH public key, in 1037 the ClientKeyExchange message ("explicit"). (This is "explicit" 1038 in ECC cipher suites except when the client uses the 1039 ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication 1040 mechanism.) 1041 struct { 1042 select (PublicValueEncoding) { 1043 case implicit: struct { }; 1044 case explicit: ECPoint ecdh_Yc; 1045 } ecdh_public; 1046 } ClientECDiffieHellmanPublic; 1048 ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte 1049 string ECPoint.point, which may represent an elliptic curve point 1050 in uncompressed or compressed format. Here the format MUST 1051 conform to what the server has requested through a Supported Point 1052 Formats Extension if this extension was used, and MUST be 1053 uncompressed if this extension was not used. 1055 struct { 1056 select (KeyExchangeAlgorithm) { 1057 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 1058 } exchange_keys; 1059 } ClientKeyExchange; 1061 Actions of the sender: 1063 The client selects an ephemeral ECDH public key corresponding to the 1064 parameters it received from the server according to the ECKAS-DH1 1065 scheme from IEEE 1363 [5]. It conveys this information to the client 1066 in the ClientKeyExchange message using the format defined above. 1068 Actions of the recipient: 1070 The server retrieves the client's ephemeral ECDH public key from the 1071 ClientKeyExchange message and checks that it is on the same elliptic 1072 curve as the server's ECDH key. 1074 5.8 Certificate Verify 1076 When this message is sent: 1078 This message is sent when the client sends a client certificate 1079 containing a public key usable for digital signatures, e.g. when the 1080 client is authenticated using the ECDSA_sign mechanism. 1082 Meaning of the message: 1084 This message contains a signature that proves possession of the 1085 private key corresponding to the public key in the client's 1086 Certificate message. 1088 Structure of this message: 1090 The TLS CertificateVerify message is extended as follows. 1092 enum { ecdsa } SignatureAlgorithm; 1094 select (SignatureAlgorithm) { 1095 case ecdsa: 1096 digitally-signed struct { 1097 opaque sha_hash[sha_size]; 1098 }; 1099 } Signature; 1101 For the ecdsa case, the signature field in the CertificateVerify 1102 message contains an ECDSA signature computed over handshake messages 1103 exchanged so far. ECDSA signatures are computed as described in 1104 Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a 1105 pair of integers r and s. These integers are both converted into 1106 byte strings of the same length as the curve order n using the 1107 conversion routine specified in Section 4.3.1 of [6]. The two byte 1108 strings are concatenated, and the result is placed in the signature 1109 field. 1111 Actions of the sender: 1113 The client computes its signature over all handshake messages sent or 1114 received starting at client hello up to but not including this 1115 message. It uses the private key corresponding to its certified 1116 public key to compute the signature which is conveyed in the format 1117 defined above. 1119 Actions of the receiver: 1121 The server extracts the client's signature from the CertificateVerify 1122 message, and verifies the signature using the public key it received 1123 in the client's Certificate message. 1125 5.9 Elliptic Curve Certificates 1127 X509 certificates containing ECC public keys or signed using ECDSA 1128 MUST comply with [11] or another RFC that replaces or extends it. 1129 Clients SHOULD use the elliptic curve domain parameters recommended 1130 in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. 1132 5.10 ECDH, ECDSA and RSA Computations 1134 All ECDH calculations (including parameter and key generation as well 1135 as the shared secret calculation) are performed according to [5] 1136 using the ECKAS-DH1 scheme with the identity map as key derivation 1137 function, so that the premaster secret is the x-coordinate of the 1138 ECDH shared secret elliptic curve point represented as an octet 1139 string. Note that this octet string (Z in IEEE 1363 terminology) as 1140 output by FE2OSP, the Field Element to Octet String Conversion 1141 Primitive, has constant length for any given field; leading zeros 1142 found in this octet string MUST NOT be truncated. 1144 Note that a new extension may be introduced in the future to allow 1145 the use of a different KDF during computation of the premaster 1146 secret. In this event, the new KDF would be used in place of the 1147 process detailed above. This may be desirable, for example, to 1148 support compatibility with the planned NIST key agreement standard. 1150 All ECDSA computations MUST be performed according to ANSI X9.62 [6] 1151 or its successors. Data to be signed/verified is hashed and the 1152 result run directly through the ECDSA algorithm with no additional 1153 hashing. The default hash function is SHA-1 [7] and sha_size (see 1154 Section 5.4 and Section 5.8) is 20. However, an alternative hash 1155 function, such as one of the new SHA hash functions specified in FIPS 1156 180-2 [7], may be used instead if the certificate containing the EC 1157 public key explicitly requires use of another hash function. (The 1158 mechanism for specifying the required hash function has not been 1159 standardized but this provision anticipates such standardization and 1160 obviates the need to update this document in response. Future PKIX 1161 RFCs may choose, for example, to specify the hash function to be used 1162 with a public key in the parameters field of subjectPublicKeyInfo.) 1164 All RSA signatures must be generated and verified according to PKCS#1 1165 [9] block type 1. 1167 6. Cipher Suites 1169 The table below defines new ECC cipher suites that use the key 1170 exchange algorithms specified in Section 2. 1172 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1173 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1174 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } 1175 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1176 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1177 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1179 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1180 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1181 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1182 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1183 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1185 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1186 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1187 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1188 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1189 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1191 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1192 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1193 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1194 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1195 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1197 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } 1198 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } 1199 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1200 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1201 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1203 Table 5: TLS ECC cipher suites 1205 [[ EDITOR: The actual cipher suite numbers will be assigned when this 1206 draft progresses to RFC. ]] 1208 The key exchange method, cipher, and hash algorithm for each of these 1209 cipher suites are easily determined by examining the name. Ciphers 1210 other than AES ciphers, and hash algorithms are defined in [2]. AES 1211 ciphers are defined in [15]. 1213 Server implementations SHOULD support all of the following cipher 1214 suites, and client implementations SHOULD support at least one of 1215 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 1216 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 1217 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 1218 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 1220 7. Security Considerations 1222 This document is based on [2], [5], [6] and [15]. The appropriate 1223 security considerations of those documents apply. 1225 One important issue that implementors and users must consider is 1226 elliptic curve selection. Guidance on selecting an appropriate 1227 elliptic curve size is given in Table 1. 1229 Beyond elliptic curve size, the main issue is elliptic curve 1230 structure. As a general principle, it is more conservative to use 1231 elliptic curves with as little algebraic structure as possible - thus 1232 random curves are more conservative than special curves such as 1233 Koblitz curves, and curves over F_p with p random are more 1234 conservative than curves over F_p with p of a special form (and 1235 curves over F_p with p random might be considered more conservative 1236 than curves over F_2^m as there is no choice between multiple fields 1237 of similar size for characteristic 2). Note, however, that algebraic 1238 structure can also lead to implementation efficiencies and 1239 implementors and users may, therefore, need to balance conservatism 1240 against a need for efficiency. Concrete attacks are known against 1241 only very few special classes of curves, such as supersingular 1242 curves, and these classes are excluded from the ECC standards that 1243 this document references [5], [6]. 1245 Another issue is the potential for catastrophic failures when a 1246 single elliptic curve is widely used. In this case, an attack on the 1247 elliptic curve might result in the compromise of a large number of 1248 keys. Again, this concern may need to be balanced against efficiency 1249 and interoperability improvements associated with widely-used curves. 1250 Substantial additional information on elliptic curve choice can be 1251 found in [4], [5], [6], [8]. 1253 Implementors and users must also consider whether they need forward 1254 secrecy. Forward secrecy refers to the property that session keys 1255 are not compromised if the static, certified keys belonging to the 1256 server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key 1257 exchange algorithms provide forward secrecy protection in the event 1258 of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. 1259 Similarly if the client is providing a static, certified key, 1260 ECDSA_sign client authentication provides forward secrecy protection 1261 in the event of client key compromise, while ECDSA_fixed_ECDH and 1262 RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy 1263 protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, 1264 with ECDSA_sign used for client authentication if necessary. Here 1265 again the security benefits of forward secrecy may need to be 1266 balanced against the improved efficiency offered by other options. 1268 8. Acknowledgments 1270 The authors wish to thank Bill Anderson and Tim Dierks. 1272 9. References 1274 9.1 Normative References 1276 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 1277 Levels", RFC 2119, March 1997. 1279 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1280 RFC 2246, January 1999. 1282 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1283 T. Wright, "Transport Layer Security (TLS) Extensions", 1284 draft-ietf-tls-rfc3546bis-01.txt (work in progress), May 2005. 1286 [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, 1287 . 1289 [5] IEEE, "Standard Specifications for Public Key Cryptography", 1290 IEEE 1363, 2000. 1292 [6] ANSI, "Public Key Cryptography For The Financial Services 1293 Industry: The Elliptic Curve Digital Signature Algorithm 1294 (ECDSA)", ANSI X9.62, 1998. 1296 [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 1298 [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1300 [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1301 1.5", PKCS 1, November 1993. 1303 [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 1304 2000, . 1306 [11] Polk, T., Housley, R., and L. Bassham, "Algorithms and 1307 Identifiers for the Internet X.509 Public Key Infrastructure 1308 Certificate and Certificate Revocation List (CRL) Profile", 1309 RFC 3279, April 2002. 1311 9.2 Informative References 1313 [12] Harper, G., Menezes, A., and S. Vanstone, "Public-Key 1314 Cryptosystems with Very Small Key Lengths", Advances in 1315 Cryptology -- EUROCRYPT '92, LNCS 658, 1993. 1317 [13] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1318 Sizes", Journal of Cryptology 14 (2001) 255-293, 1319 . 1321 [14] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1322 Version 3.0", November 1996, 1323 . 1325 [15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1326 Transport Layer Security (TLS)", RFC 3268, June 2002. 1328 Authors' Addresses 1330 Vipul Gupta 1331 Sun Microsystems Laboratories 1332 16 Network Circle 1333 MS UMPK16-160 1334 Menlo Park, CA 94025 1335 US 1337 Phone: +1 650 786 7551 1338 Email: vipul.gupta@sun.com 1340 Simon Blake-Wilson 1341 Basic Commerce & Industries, Inc. 1342 96 Spandia Ave 1343 Unit 606 1344 Toronto, ON M6G 2T6 1345 CA 1347 Phone: +1 416 214 5961 1348 Email: sblakewilson@bcisse.com 1350 Bodo Moeller 1351 University of Calgary 1352 Dept of Math & Stats 1353 2500 University Dr NW 1354 Calgary, AB T2N 1N4 1355 CA 1357 Phone: +1 403 220 5735 1358 Email: bodo@openssl.org 1360 Chris Hawk 1361 Corriente Networks 1363 Email: chris@corriente.net 1364 Nelson Bolyard 1366 Email: nelson@bolyard.com 1368 Intellectual Property Statement 1370 The IETF takes no position regarding the validity or scope of any 1371 Intellectual Property Rights or other rights that might be claimed to 1372 pertain to the implementation or use of the technology described in 1373 this document or the extent to which any license under such rights 1374 might or might not be available; nor does it represent that it has 1375 made any independent effort to identify any such rights. Information 1376 on the procedures with respect to rights in RFC documents can be 1377 found in BCP 78 and BCP 79. 1379 Copies of IPR disclosures made to the IETF Secretariat and any 1380 assurances of licenses to be made available, or the result of an 1381 attempt made to obtain a general license or permission for the use of 1382 such proprietary rights by implementers or users of this 1383 specification can be obtained from the IETF on-line IPR repository at 1384 http://www.ietf.org/ipr. 1386 The IETF invites any interested party to bring to its attention any 1387 copyrights, patents or patent applications, or other proprietary 1388 rights that may cover technology that may be required to implement 1389 this standard. Please address the information to the IETF at 1390 ietf-ipr@ietf.org. 1392 Disclaimer of Validity 1394 This document and the information contained herein are provided on an 1395 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1396 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1397 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1398 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1399 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1400 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1402 Copyright Statement 1404 Copyright (C) The Internet Society (2005). This document is subject 1405 to the rights, licenses and restrictions contained in BCP 78, and 1406 except as set forth therein, the authors retain all their rights. 1408 Acknowledgment 1410 Funding for the RFC Editor function is currently provided by the 1411 Internet Society.