idnits 2.17.00 (12 Aug 2021) /tmp/idnits13335/draft-ietf-tls-ecc-11.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 1435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1412. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1425. ** 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 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 799 has weird spacing: '...rveType cur...' == Line 812 has weird spacing: '... opaque k <1....' == Line 814 has weird spacing: '... opaque k1 <1...' == Line 815 has weird spacing: '... opaque k2 <1...' == Line 816 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 (September 16, 2005) is 6090 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 220 == Unused Reference: '13' is defined on line 1348, 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 normative reference: RFC 2434 (ref. '12') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3268 (ref. '16') (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: March 20, 2006 S. Blake-Wilson 5 BCI 6 B. Moeller 7 University of Calgary 8 C. Hawk 9 Corriente Networks 10 N. Bolyard 11 September 16, 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 March 20, 2006. 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 90 10.1 Normative References . . . . . . . . . . . . . . . . . . 33 91 10.2 Informative References . . . . . . . . . . . . . . . . . 33 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 93 Intellectual Property and Copyright Statements . . . . . . . 36 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 [14], 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 Smaller key sizes result in power, bandwidth and computational 116 savings that make ECC especially attractive for constrained 117 environments. 119 This document describes additions to TLS to support ECC. In 120 particular, it defines 122 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement 123 scheme with long-term or ephemeral keys to establish the TLS 124 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 discusses security 139 considerations. Section 8 describes IANA considerations for the name 140 spaces created by this document. Section 9 gives acknowledgments. 141 This is followed by the lists of normative and informative references 142 cited in this document, the authors' contact information, and 143 statements on intellectual property rights and copyrights. 145 Implementation of this specification requires familiarity with TLS 146 [2], TLS extensions [3] and ECC [4][5][6][8]. 148 2. Key Exchange Algorithms 150 This document introduces five new ECC-based key exchange algorithms 151 for TLS. All of them use ECDH to compute the TLS premaster secret 152 and differ only in the lifetime of ECDH keys (long-term or ephemeral) 153 and the mechanism (if any) used to authenticate them. The derivation 154 of the TLS master secret from the premaster secret and the subsequent 155 generation of bulk encryption/MAC keys and initialization vectors is 156 independent of the key exchange algorithm and not impacted by the 157 introduction of ECC. 159 The table below summarizes the new key exchange algorithms which 160 mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]), 161 respectively. 163 Key 164 Exchange 165 Algorithm Description 166 --------- ----------- 168 ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. 170 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. 172 ECDH_RSA Fixed ECDH with RSA-signed certificates. 174 ECDHE_RSA Ephemeral ECDH with RSA signatures. 176 ECDH_anon Anonymous ECDH, no signatures. 178 Table 2: ECC key exchange algorithms 180 The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward 181 secrecy. With ECDHE_RSA, a server can reuse its existing RSA 182 certificate and easily comply with a constrained client's elliptic 183 curve preferences (see Section 4). However, the computational cost 184 incurred by a server is higher for ECDHE_RSA than for the traditional 185 RSA key exchange which does not provide forward secrecy. 187 The ECDH_RSA mechanism requires a server to acquire an ECC 188 certificate but the certificate issuer can still use an existing RSA 189 key for signing. This eliminates the need to update the trusted key 190 store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for 191 the server as well as the certification authority and is best suited 192 for constrained devices unable to support RSA. 194 The anonymous key exchange algorithm does not provide authentication 195 of the server or the client. Like other anonymous TLS key exchanges, 196 it is subject to man-in-the-middle attacks. Implementations of this 197 algorithm SHOULD provide authentication by other means. 199 Note that there is no structural difference between ECDH and ECDSA 200 keys. A certificate issuer may use X509.v3 keyUsage and 201 extendedKeyUsage extensions to restrict the use of an ECC public key 202 to certain computations. This document refers to an ECC key as ECDH- 203 capable if its use in ECDH is permitted. ECDSA-capable is defined 204 similarly. 206 Client Server 207 ------ ------ 209 ClientHello --------> 210 ServerHello 211 Certificate* 212 ServerKeyExchange* 213 CertificateRequest*+ 214 <-------- ServerHelloDone 215 Certificate*+ 216 ClientKeyExchange 217 CertificateVerify*+ 218 [ChangeCipherSpec] 219 Finished --------> 220 [ChangeCipherSpec] 221 <-------- Finished 223 Application Data <-------> Application Data 225 * message is not sent under some conditions 226 + message is not sent unless client authentication 227 is desired 229 Figure 1: Message flow in a full TLS handshake 231 Figure 1 shows all messages involved in the TLS key establishment 232 protocol (aka full handshake). The addition of ECC has direct impact 233 only on the ClientHello, the ServerHello, the server's Certificate 234 message, the ServerKeyExchange, the ClientKeyExchange, the 235 CertificateRequest, the client's Certificate message, and the 236 CertificateVerify. Next, we describe each ECC key exchange algorithm 237 in greater detail in terms of the content and processing of these 238 messages. For ease of exposition, we defer discussion of client 239 authentication and associated messages (identified with a + in 240 Figure 1) until Section 3 and of the optional ECC-specific extensions 241 (which impact the Hello messages) until Section 4. 243 2.1 ECDH_ECDSA 245 In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable 246 public key and be signed with ECDSA. 248 A ServerKeyExchange MUST NOT be sent (the server's certificate 249 contains all the necessary keying information required by the client 250 to arrive at the premaster secret). 252 The client generates an ECDH key pair on the same curve as the 253 server's long-term public key and send its public key in the 254 ClientKeyExchange message (except when using client authentication 255 algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the 256 modifications from Section 3.2 or Section 3.3 apply). 258 Both client and server perform an ECDH operation and use the 259 resultant shared secret as the premaster secret. All ECDH 260 calculations are performed as specified in Section 5.10 262 2.2 ECDHE_ECDSA 264 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- 265 capable public key and be signed with ECDSA. 267 The server sends its ephemeral ECDH public key and a specification of 268 the corresponding curve in the ServerKeyExchange message. These 269 parameters MUST be signed with ECDSA using the private key 270 corresponding to the public key in the server's Certificate. 272 The client generates an ECDH key pair on the same curve as the 273 server's ephemeral ECDH key and send its public key in the 274 ClientKeyExchange message. 276 Both client and server perform an ECDH operation (Section 5.10) and 277 use the resultant shared secret as the premaster secret. 279 2.3 ECDH_RSA 281 This key exchange algorithm is the same as ECDH_ECDSA except the 282 server's certificate MUST be signed with RSA rather than ECDSA. 284 2.4 ECDHE_RSA 286 This key exchange algorithm is the same as ECDHE_ECDSA except the 287 server's certificate MUST contain an RSA public key authorized for 288 signing and the signature in the ServerKeyExchange message must be 289 computed with the corresponding RSA private key. The server 290 certificate MUST be signed with RSA. 292 2.5 ECDH_anon 294 In ECDH_anon, the server's Certificate, the CertificateRequest, the 295 client's Certificate, and the CertificateVerify messages MUST NOT be 296 sent. 298 The server MUST send an ephemeral ECDH public key and a specification 299 of the corresponding curve in the ServerKeyExchange message. These 300 parameters MUST NOT be signed. 302 The client generates an ECDH key pair on the same curve as the 303 server's ephemeral ECDH key and send its public key in the 304 ClientKeyExchange message. 306 Both client and server perform an ECDH operation and use the 307 resultant shared secret as the premaster secret. All ECDH 308 calculations are performed as specified in Section 5.10. 310 Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA 311 key exchange algorithms require the server's certificate to be signed 312 with a particular signature scheme, this specification (following the 313 similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2]) does not 314 impose restrictions on signature schemes used elsewhere in the 315 certificate chain. (Often such restrictions will be useful, and it 316 is expected that this will be taken into account in certification 317 authorities' signing practices. However, such restrictions are not 318 strictly required in general: Even if it is beyond the capabilities 319 of a client to completely validate a given chain, the client may be 320 able to validate the server's certificate by relying on a trust 321 anchor that appears as one of the intermediate certificates in the 322 chain.) 324 3. Client Authentication 326 This document defines three new client authentication mechanisms 327 named after the type of client certificate involved: ECDSA_sign, 328 ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is 329 usable with any of the non-anonymous ECC key exchange algorithms 330 described in Section 2 as well as other non-anonymous (non-ECC) key 331 exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and 332 RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. 333 Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the 334 use of a long-term ECDH client key would jeopardize the forward 335 secrecy property of these algorithms. 337 The server can request ECC-based client authentication by including 338 one or more of these certificate types in its CertificateRequest 339 message. The server must not include any certificate types that are 340 prohibited for the negotiated key exchange algorithm. The client 341 must check if it possesses a certificate appropriate for any of the 342 methods suggested by the server and is willing to use it for 343 authentication. 345 If these conditions are not met, the client should send a client 346 Certificate message containing no certificates. In this case, the 347 ClientKeyExchange should be sent as described in Section 2 and the 348 CertificateVerify should not be sent. If the server requires client 349 authentication, it may respond with a fatal handshake failure alert. 351 If the client has an appropriate certificate and is willing to use it 352 for authentication, it must send that certificate in the client's 353 Certificate message (as per Section 5.6) and prove possession of the 354 private key corresponding to the certified key. The process of 355 determining an appropriate certificate and proving possession is 356 different for each authentication mechanism and described below. 358 NOTE: It is permissible for a server to request (and the client to 359 send) a client certificate of a different type than the server 360 certificate. 362 3.1 ECDSA_sign 364 To use this authentication mechanism, the client MUST possess a 365 certificate containing an ECDSA-capable public key and signed with 366 ECDSA. 368 The client proves possession of the private key corresponding to the 369 certified key by including a signature in the CertificateVerify 370 message as described in Section 5.8. 372 3.2 ECDSA_fixed_ECDH 374 To use this authentication mechanism, the client MUST possess a 375 certificate containing an ECDH-capable public key and that 376 certificate MUST be signed with ECDSA. Furthermore, the client's 377 ECDH key MUST be on the same elliptic curve as the server's long-term 378 (certified) ECDH key. This might limit use of this mechanism to 379 closed environments. In situations where the client has an ECC key 380 on a different curve, it would have to authenticate either using 381 ECDSA_sign or a non-ECC mechanism (e.g. RSA). Using fixed ECDH for 382 both servers and clients is computationally more efficient than 383 mechanisms providing forward secrecy. 385 When using this authentication mechanism, the client MUST send an 386 empty ClientKeyExchange as described in Section 5.7 and MUST NOT send 387 the CertificateVerify message. The ClientKeyExchange is empty since 388 the client's ECDH public key required by the server to compute the 389 premaster secret is available inside the client's certificate. The 390 client's ability to arrive at the same premaster secret as the server 391 (demonstrated by a successful exchange of Finished messages) proves 392 possession of the private key corresponding to the certified public 393 key and the CertificateVerify message is unnecessary. 395 3.3 RSA_fixed_ECDH 397 This authentication mechanism is identical to ECDSA_fixed_ECDH except 398 the client's certificate MUST be signed with RSA. 400 Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH 401 client authentication mechanisms require the clients's certificate to 402 be signed with a particular signature scheme, this specification does 403 not impose restrictions on signature schemes used elsewhere in the 404 certificate chain. (Often such restrictions will be useful, and it 405 is expected that this will be taken into account in certification 406 authorities' signing practices. However, such restrictions are not 407 strictly required in general: Even if it is beyond the capabilities 408 of a server to completely validate a given chain, the server may be 409 able to validate the clients certificate by relying on a trust anchor 410 that appears as one of the intermediate certificates in the chain.) 412 4. TLS Extensions for ECC 414 Two new TLS extensions are defined in this specification: (i) the 415 Supported Elliptic Curves Extension, and (ii) the Supported Point 416 Formats Extension. These allow negotiating the use of specific 417 curves and point formats (e.g. compressed vs. uncompressed), 418 respectively, during a handshake starting a new session. These 419 extensions are especially relevant for constrained clients that may 420 only support a limited number of curves or point formats. They 421 follow the general approach outlined in [3]; message details are 422 specified in Section 5. The client enumerates the curves it supports 423 and the point formats it can parse by including the appropriate 424 extensions in its ClientHello message. The server similarly 425 enumerates the point formats it can parse by including an extension 426 in its ServerHello message. 428 A TLS client that proposes ECC cipher suites in its ClientHello 429 message SHOULD include these extensions. Servers implementing ECC 430 cipher suites MUST support these extensions, and when a client uses 431 these extensions, servers MUST NOT negotiate the use of an ECC cipher 432 suite unless they can complete the handshake while respecting the 433 choice of curves and compression techniques specified by the client. 434 This eliminates the possibility that a negotiated ECC handshake will 435 be subsequently aborted due to a client's inability to deal with the 436 server's EC key. 438 These extensions MUST NOT be included if the client does not propose 439 any ECC cipher suites. A client that proposes ECC cipher suites may 440 choose not to include these extension. In this case, the server is 441 free to choose any one of the elliptic curves or point formats listed 442 in Section 5. That section also describes the structure and 443 processing of these extensions in greater detail. 445 In the case of session resumption, the server simply ignores the 446 Supported Elliptic Curves Extension and the Supported Point Formats 447 Extension as appearing in the current ClientHello message. These 448 extensions only play a role during handshakes negotiating a new 449 session. 451 5. Data Structures and Computations 453 This section specifies the data structures and computations used by 454 ECC-based key mechanisms specified in Section 2, Section 3 and 455 Section 4. The presentation language used here is the same as that 456 used in TLS [2]. Since this specification extends TLS, these 457 descriptions should be merged with those in the TLS specification and 458 any others that extend TLS. This means that enum types may not 459 specify all possible values and structures with multiple formats 460 chosen with a select() clause may not indicate all possible cases. 462 5.1 Client Hello Extensions 464 This section specifies two TLS extensions that can be included with 465 the ClientHello message as described in [3], the Supported Elliptic 466 Curves Extension and the Supported Point Formats Extension. 468 When these extensions are sent: 470 The extensions SHOULD be sent along with any ClientHello message that 471 proposes ECC cipher suites. 473 Meaning of these extensions: 475 These extensions allow a client to enumerate the elliptic curves it 476 supports and/or the point formats it can parse. 478 Structure of these extensions: 480 The general structure of TLS extensions is described in [3] and this 481 specification adds two new types to ExtensionType. 483 enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType; 485 [[ EDITOR: The values used for elliptic_curves and ec_point_formats 486 have been left as ??. These values will be assigned when this draft 487 progresses to RFC. (The examples below will have to be changed 488 accordingly.) ]] 490 elliptic_curves (Supported Elliptic Curves Extension): Indicates the 491 set of elliptic curves supported by the client. For this 492 extension, the opaque extension_data field contains 493 EllipticCurveList. 495 ec_point_formats (Supported Point Formats Extension): Indicates the 496 set of point formats that the client can parse. For this 497 extension, the opaque extension_data field contains 498 ECPointFormatList. 500 enum { 501 sect163k1 (1), sect163r1 (2), sect163r2 (3), 502 sect193r1 (4), sect193r2 (5), sect233k1 (6), 503 sect233r1 (7), sect239k1 (8), sect283k1 (9), 504 sect283r1 (10), sect409k1 (11), sect409r1 (12), 505 sect571k1 (13), sect571r1 (14), secp160k1 (15), 506 secp160r1 (16), secp160r2 (17), secp192k1 (18), 507 secp192r1 (19), secp224k1 (20), secp224r1 (21), 508 secp256k1 (22), secp256r1 (23), secp384r1 (24), 509 secp521r1 (25), 510 reserved (0xFE00..0xFEFF), 511 arbitrary_explicit_prime_curves(0xFF01), 512 arbitrary_explicit_char2_curves(0xFF02), 513 (0xFFFF) 514 } NamedCurve; 516 sect163k1, etc: Indicates support of the corresponding named curve 517 or class of explicitly defined curves. The named curves defined 518 here are those specified in SEC 2 [10]. Note that many of these 519 curves are also recommended in ANSI X9.62 [6] and FIPS 186-2 [8]. 520 Values 0xFE00 through 0xFEFF are reserved for private use. Values 521 0xFF01 and 0xFF02 indicate that the client supports arbitrary 522 prime and characteristic-2 curves, respectively (the curve 523 parameters must be encoded explicitly in ECParameters). 525 The NamedCurve name space is maintained by IANA. See Section 8 for 526 information on how new value assignments are added. 528 struct { 529 NamedCurve elliptic_curve_list<1..2^8-1> 530 } EllipticCurveList; 532 Items in elliptic_curve_list are ordered according to the client's 533 preferences (favorite choice first). 535 As an example, a client that only supports secp192r1 (aka NIST P-192; 536 value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) 537 and prefers to use secp192r1 would include a TLS extension consisting 538 of the following octets: 540 00 ?? 00 06 00 04 00 13 00 15 542 A client that supports arbitrary explicit characteristic-2 curves 543 (value 0xFF02) would include an extension consisting of the following 544 octets: 546 00 ?? 00 04 00 02 FF 02 548 enum { uncompressed (0), ansiX962_compressed_prime (1), 549 ansiX962_compressed_char2 (2), reserved (248..255) 550 } ECPointFormat; 552 struct { 553 ECPointFormat ec_point_format_list<1..2^8-1> 554 } ECPointFormatList; 556 Three point formats are included in the definition of ECPointFormat 557 above. The uncompressed point format is the default format in that 558 implementations of this document MUST support it for all of their 559 supported curves. Compressed point formats reduce bandwidth by 560 including only the x-coordinate and a single bit of the y-coordinate 561 of the point. Implementations of this document MAY support the 562 ansiX962_compressed_prime and ansiX962_compressed_char2 formats, 563 where the former applies only to prime curves and the latter applies 564 only to characteristic-2 curves. (These formats are specified in 565 [6].) Values 248 through 255 are reserved for private use. 567 The ECPointFormat name space is maintained by IANA. See Section 8 568 for information on how new value assignments are added. 570 Items in ec_point_format_list are ordered according to the client's 571 preferences (favorite choice first). 573 A client that can parse only the uncompressed point format (value 0) 574 includes an extension consisting of the following octets: 576 00 ?? 00 02 01 00 578 A client that in the case of prime fields prefers the compressed 579 format (ansiX962_compressed_prime, value 1) over the uncompressed 580 format (value 0), but in the case of characteristic-2 fields prefers 581 the uncompressed format (value 0) over the compressed format 582 (ansiX962_compressed_char2, value 2), may indicate these preferences 583 by including an extension consisting of the following octets: 585 00 ?? 00 04 03 01 00 02 587 Actions of the sender: 589 A client that proposes ECC cipher suites in its ClientHello message 590 appends these extensions (along with any others), enumerating the 591 curves it supports and the point formats it can parse. Clients 592 SHOULD send both the Supported Elliptic Curves Extension and the 593 Supported Point Formats Extension. If the Supported Point Formats 594 Extension is indeed sent, it MUST contain the value 0 (uncompressed) 595 as one of the items in the list of point formats. 597 Actions of the receiver: 599 A server that receives a ClientHello containing one or both of these 600 extensions MUST use the client's enumerated capabilities to guide its 601 selection of an appropriate cipher suite. One of the proposed ECC 602 cipher suites must be negotiated only if the server can successfully 603 complete the handshake while using the curves and point formats 604 supported by the client (cf. Section 5.3 and Section 5.4). 606 NOTE: A server participating in an ECDHE-ECDSA key exchange may use 607 different curves for (i) the ECDSA key in its certificate, and (ii) 608 the ephemeral ECDH key in the ServerKeyExchange message. The server 609 must consider the "elliptic_curves" extension in selecting both of 610 these curves. 612 If a server does not understand the "elliptic_curves" extension or is 613 unable to complete the ECC handshake while restricting itself to the 614 enumerated curves, it MUST NOT negotiate the use of an ECC cipher 615 suite. Depending on what other cipher suites are proposed by the 616 client and supported by the server, this may result in a fatal 617 handshake failure alert due to the lack of common cipher suites. 619 5.2 Server Hello Extension 621 This section specifies a TLS extension that can be included with the 622 ServerHello message as described in [3], the Supported Point Formats 623 Extension. 625 When this extension is sent: 627 The Supported Point Formats Extension is included in a ServerHello 628 message in response to a ClientHello message containing the Supported 629 Point Formats Extension when negotiating an ECC cipher suite. 631 Meaning of this extensions: 633 This extension allows a server to enumerate the point formats it can 634 parse (for the curve that will appear in its ServerKeyExchange 635 message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key 636 exchange algorithm, or for the curve that is used in the server's 637 public key that will appear in its Certificate message when using the 638 ECDH_ECDSA or ECDH_RSA key exchange algorithm). 640 Structure of this extension: 642 The server's Supported Point Formats Extension has the same structure 643 as the client's Supported Point Formats Extension. Items in 644 elliptic_curve_list here are ordered according to the server's 645 preference (favorite choice first). Note that the server may include 646 items that were not found in the client's list (e.g., the server may 647 prefer to receive points in compressed format even when a client 648 cannot parse this format: the same client may nevertheless be capable 649 to output points in compressed format). 651 Actions of the sender: 653 A server that selects an ECC cipher suite in response to a 654 ClientHello message including a Supported Point Formats Extension 655 appends this extension (along with others) to its ServerHello 656 message, enumerating the point formats it can parse. The Supported 657 Point Formats Extension, when used, MUST contain the value 0 658 (uncompressed) as one of the items in the list of point formats. 660 Actions of the receiver: 662 A client that receives a ServerHello message containing a Supported 663 Point Formats Extension MUST respect the server's choice of point 664 formats during the handshake (cf. Section 5.6 and Section 5.7). If 665 no Supported Point Formats Extension is received with the 666 ServerHello, this is equivalent to an extension allowing only the 667 uncompressed point format. 669 5.3 Server Certificate 671 When this message is sent: 673 This message is sent in all non-anonymous ECC-based key exchange 674 algorithms. 676 Meaning of this message: 678 This message is used to authentically convey the server's static 679 public key to the client. The following table shows the server 680 certificate type appropriate for each key exchange algorithm. ECC 681 public keys must be encoded in certificates as described in 682 Section 5.9. 684 NOTE: The server's Certificate message is capable of carrying a chain 685 of certificates. The restrictions mentioned in Table 3 apply only to 686 the server's certificate (first in the chain). 688 Key Exchange Algorithm Server Certificate Type 689 ---------------------- ----------------------- 691 ECDH_ECDSA Certificate must contain an 692 ECDH-capable public key. It 693 must be signed with ECDSA. 695 ECDHE_ECDSA Certificate must contain an 696 ECDSA-capable public key. It 697 must be signed with ECDSA. 699 ECDH_RSA Certificate must contain an 700 ECDH-capable public key. It 701 must be signed with RSA. 703 ECDHE_RSA Certificate must contain an 704 RSA public key authorized for 705 use in digital signatures. It 706 must be signed with RSA. 708 Table 3: Server certificate types 710 Structure of this message: 712 Identical to the TLS Certificate format. 714 Actions of the sender: 716 The server constructs an appropriate certificate chain and conveys it 717 to the client in the Certificate message. If the client has used a 718 Supported Elliptic Curves Extension, the public key in the server's 719 certificate MUST respect the client's choice of elliptic curves; in 720 particular, the public key MUST employ a named curve (not the same 721 curve as an explicit curve) unless the client has indicated support 722 for explicit curves of the appropriate type. If the client has used 723 a Supported Point Formats Extension, both the server's public key 724 point and (in the case of an explicit curve) the curve's base point 725 MUST respect the client's choice of point formats. (A server that 726 cannot satisfy these requirements must not choose an ECC cipher suite 727 in its ServerHello message.) 729 Actions of the receiver: 731 The client validates the certificate chain, extracts the server's 732 public key, and checks that the key type is appropriate for the 733 negotiated key exchange algorithm. 735 5.4 Server Key Exchange 737 When this message is sent: 739 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and 740 ECDH_anon key exchange algorithms. 742 Meaning of this message: 744 This message is used to convey the server's ephemeral ECDH public key 745 (and the corresponding elliptic curve domain parameters) to the 746 client. 748 Structure of this message: 750 enum { explicit_prime (1), explicit_char2 (2), 751 named_curve (3), reserved(248..255) } ECCurveType; 753 explicit_prime: Indicates the elliptic curve domain parameters are 754 conveyed verbosely, and the underlying finite field is a prime 755 field. 757 explicit_char2: Indicates the elliptic curve domain parameters are 758 conveyed verbosely, and the underlying finite field is a 759 characteristic-2 field. 761 named_curve: Indicates that a named curve is used. This option 762 SHOULD be used when applicable. 764 Values 248 through 255 are reserved for private use. 766 The ECCurveType name space is maintained by IANA. See Section 8 for 767 information on how new value assignments are added. 769 struct { 770 opaque a <1..2^8-1>; 771 opaque b <1..2^8-1>; 772 } ECCurve; 774 a, b: These parameters specify the coefficients of the elliptic 775 curve. Each value contains the byte string representation of a 776 field element following the conversion routine in Section 4.3.3 of 777 ANSI X9.62 [6]. 779 struct { 780 opaque point <1..2^8-1>; 781 } ECPoint; 783 point: This is the byte string representation of an elliptic curve 784 point following the conversion routine in Section 4.3.6 of ANSI 785 X9.62 [6]. This byte string may represent an elliptic curve point 786 in uncompressed, or compressed format; it MUST conform to what the 787 client has requested through a Supported Point Formats Extension 788 if this extension was used. 790 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 792 ec_basis_trinomial: Indicates representation of a characteristic-2 793 field using a trinomial basis. 795 ec_basis_pentanomial: Indicates representation of a characteristic-2 796 field using a pentanomial basis. 798 struct { 799 ECCurveType curve_type; 800 select (curve_type) { 801 case explicit_prime: 802 opaque prime_p <1..2^8-1>; 803 ECCurve curve; 804 ECPoint base; 805 opaque order <1..2^8-1>; 806 opaque cofactor <1..2^8-1>; 807 case explicit_char2: 808 uint16 m; 809 ECBasisType basis; 810 select (basis) { 811 case ec_trinomial: 812 opaque k <1..2^8-1>; 813 case ec_pentanomial: 814 opaque k1 <1..2^8-1>; 815 opaque k2 <1..2^8-1>; 816 opaque k3 <1..2^8-1>; 817 }; 818 ECCurve curve; 819 ECPoint base; 820 opaque order <1..2^8-1>; 821 opaque cofactor <1..2^8-1>; 822 case named_curve: 823 NamedCurve namedcurve; 824 }; 826 } ECParameters; 828 curve_type: This identifies the type of the elliptic curve domain 829 parameters. 831 prime_p: This is the odd prime defining the field Fp. 833 curve: Specifies the coefficients a and b of the elliptic curve E. 835 base: Specifies the base point G on the elliptic curve. 837 order: Specifies the order n of the base point. 839 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) 840 represents the number of points on the elliptic curve E defined 841 over the field Fq (either Fp or F2^m). 843 m: This is the degree of the characteristic-2 field F2^m. 845 k: The exponent k for the trinomial basis representation x^m + x^k 846 +1. 848 k1, k2, k3: The exponents for the pentanomial representation x^m + 849 x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). 851 namedcurve: Specifies a recommended set of elliptic curve domain 852 parameters. All those values of NamedCurve are allowed that refer 853 to a specific curve. Values of NamedCurve that indicate support 854 for a class of explicitly defined curves are not allowed here 855 (they are only permissible in the ClientHello extension); this 856 applies to arbitrary_explicit_prime_curves(0xFF01) and 857 arbitrary_explicit_char2_curves(0xFF02). 859 struct { 860 ECParameters curve_params; 861 ECPoint public; 862 } ServerECDHParams; 864 curve_params: Specifies the elliptic curve domain parameters 865 associated with the ECDH public key. 867 public: The ephemeral ECDH public key. 869 The ServerKeyExchange message is extended as follows. 871 enum { ec_diffie_hellman } KeyExchangeAlgorithm; 873 ec_diffie_hellman: Indicates the ServerKeyExchange message contains 874 an ECDH public key. 876 select (KeyExchangeAlgorithm) { 877 case ec_diffie_hellman: 878 ServerECDHParams params; 879 Signature signed_params; 880 } ServerKeyExchange; 882 params: Specifies the ECDH public key and associated domain 883 parameters. 885 signed_params: A hash of the params, with the signature appropriate 886 to that hash applied. The private key corresponding to the 887 certified public key in the server's Certificate message is used 888 for signing. 890 enum { ecdsa } SignatureAlgorithm; 892 select (SignatureAlgorithm) { 893 case ecdsa: 894 digitally-signed struct { 895 opaque sha_hash[sha_size]; 896 }; 897 } Signature; 899 NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange 900 algorithm and "anonymous" for ECDH_anon. These cases are defined in 901 TLS [2]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA 902 signatures are generated and verified as described in Section 5.10. 903 As per ANSI X9.62, an ECDSA signature consists of a pair of integers 904 r and s. These integers are both converted into byte strings of the 905 same length as the curve order n using the conversion routine 906 specified in Section 4.3.1 of [6]. The two byte strings are 907 concatenated, and the result is placed in the signature field. 909 Actions of the sender: 911 The server selects elliptic curve domain parameters and an ephemeral 912 ECDH public key corresponding to these parameters according to the 913 ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to 914 the client in the ServerKeyExchange message using the format defined 915 above. 917 Actions of the recipient: 919 The client verifies the signature (when present) and retrieves the 920 server's elliptic curve domain parameters and ephemeral ECDH public 921 key from the ServerKeyExchange message. 923 5.5 Certificate Request 925 When this message is sent: 927 This message is sent when requesting client authentication. 929 Meaning of this message: 931 The server uses this message to suggest acceptable client 932 authentication methods. 934 Structure of this message: 936 The TLS CertificateRequest message is extended as follows. 938 enum { 939 ecdsa_sign(??), rsa_fixed_ecdh(??), 940 ecdsa_fixed_ecdh(??), (255) 941 } ClientCertificateType; 943 ecdsa_sign, etc Indicates that the server would like to use the 944 corresponding client authentication method specified in Section 3. 946 [[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and 947 ecdsa_fixed_ecdh have been left as ??. These values will be 948 assigned when this draft progresses to RFC. Earlier versions of 949 this draft used the values 5, 6, and 7 - however these values have 950 been removed since they are used differently by SSL 3.0 [15] and 951 their use by TLS is being deprecated. ]] 953 Actions of the sender: 955 The server decides which client authentication methods it would like 956 to use, and conveys this information to the client using the format 957 defined above. 959 Actions of the receiver: 961 The client determines whether it has a suitable certificate for use 962 with any of the requested methods, and decides whether or not to 963 proceed with client authentication. 965 5.6 Client Certificate 967 When this message is sent: 969 This message is sent in response to a CertificateRequest when a 970 client has a suitable certificate and has decided to proceed with 971 client authentication. (Note that if the server has used a Supported 972 Point Formats Extension, a certificate can only be considered 973 suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and 974 ECDSA_fixed_ECDH authentication methods if the public key point 975 specified in it respects the server's choice of point formats. If no 976 Supported Point Formats Extension has been used, a certificate can 977 only be considered suitable for use with these authentication methods 978 if the point is represented in uncompressed point format.) 980 Meaning of this message: 982 This message is used to authentically convey the client's static 983 public key to the server. The following table summarizes what client 984 certificate types are appropriate for the ECC-based client 985 authentication mechanisms described in Section 3. ECC public keys 986 must be encoded in certificates as described in Section 5.9. 988 NOTE: The client's Certificate message is capable of carrying a chain 989 of certificates. The restrictions mentioned in Table 4 apply only to 990 the client's certificate (first in the chain). 992 Client 993 Authentication Method Client Certificate Type 994 --------------------- ----------------------- 996 ECDSA_sign Certificate MUST contain an 997 ECDSA-capable public key and 998 be signed with ECDSA. 1000 ECDSA_fixed_ECDH Certificate MUST contain an 1001 ECDH-capable public key on the 1002 same elliptic curve as the server's 1003 long-term ECDH key. This certificate 1004 MUST be signed with ECDSA. 1006 RSA_fixed_ECDH Certificate MUST contain an 1007 ECDH-capable public key on the 1008 same elliptic curve as the server's 1009 long-term ECDH key. This certificate 1010 MUST be signed with RSA. 1012 Table 4: Client certificate types 1014 Structure of this message: 1016 Identical to the TLS client Certificate format. 1018 Actions of the sender: 1020 The client constructs an appropriate certificate chain, and conveys 1021 it to the server in the Certificate message. 1023 Actions of the receiver: 1025 The TLS server validates the certificate chain, extracts the client's 1026 public key, and checks that the key type is appropriate for the 1027 client authentication method. 1029 5.7 Client Key Exchange 1031 When this message is sent: 1033 This message is sent in all key exchange algorithms. If client 1034 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 1035 message is empty. Otherwise, it contains the client's ephemeral ECDH 1036 public key. 1038 Meaning of the message: 1040 This message is used to convey ephemeral data relating to the key 1041 exchange belonging to the client (such as its ephemeral ECDH public 1042 key). 1044 Structure of this message: 1046 The TLS ClientKeyExchange message is extended as follows. 1048 enum { implicit, explicit } PublicValueEncoding; 1050 implicit, explicit: For ECC cipher suites, this indicates whether 1051 the client's ECDH public key is in the client's certificate 1052 ("implicit") or is provided, as an ephemeral ECDH public key, in 1053 the ClientKeyExchange message ("explicit"). (This is "explicit" 1054 in ECC cipher suites except when the client uses the 1055 ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication 1056 mechanism.) 1057 struct { 1058 select (PublicValueEncoding) { 1059 case implicit: struct { }; 1060 case explicit: ECPoint ecdh_Yc; 1061 } ecdh_public; 1062 } ClientECDiffieHellmanPublic; 1064 ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte 1065 string ECPoint.point, which may represent an elliptic curve point 1066 in uncompressed or compressed format. Here the format MUST 1067 conform to what the server has requested through a Supported Point 1068 Formats Extension if this extension was used, and MUST be 1069 uncompressed if this extension was not used. 1071 struct { 1072 select (KeyExchangeAlgorithm) { 1073 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 1074 } exchange_keys; 1075 } ClientKeyExchange; 1077 Actions of the sender: 1079 The client selects an ephemeral ECDH public key corresponding to the 1080 parameters it received from the server according to the ECKAS-DH1 1081 scheme from IEEE 1363 [5]. It conveys this information to the client 1082 in the ClientKeyExchange message using the format defined above. 1084 Actions of the recipient: 1086 The server retrieves the client's ephemeral ECDH public key from the 1087 ClientKeyExchange message and checks that it is on the same elliptic 1088 curve as the server's ECDH key. 1090 5.8 Certificate Verify 1092 When this message is sent: 1094 This message is sent when the client sends a client certificate 1095 containing a public key usable for digital signatures, e.g. when the 1096 client is authenticated using the ECDSA_sign mechanism. 1098 Meaning of the message: 1100 This message contains a signature that proves possession of the 1101 private key corresponding to the public key in the client's 1102 Certificate message. 1104 Structure of this message: 1106 The TLS CertificateVerify message is extended as follows. 1108 enum { ecdsa } SignatureAlgorithm; 1110 select (SignatureAlgorithm) { 1111 case ecdsa: 1112 digitally-signed struct { 1113 opaque sha_hash[sha_size]; 1114 }; 1115 } Signature; 1117 For the ecdsa case, the signature field in the CertificateVerify 1118 message contains an ECDSA signature computed over handshake messages 1119 exchanged so far. ECDSA signatures are computed as described in 1120 Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a 1121 pair of integers r and s. These integers are both converted into 1122 byte strings of the same length as the curve order n using the 1123 conversion routine specified in Section 4.3.1 of [6]. The two byte 1124 strings are concatenated, and the result is placed in the signature 1125 field. 1127 Actions of the sender: 1129 The client computes its signature over all handshake messages sent or 1130 received starting at client hello up to but not including this 1131 message. It uses the private key corresponding to its certified 1132 public key to compute the signature which is conveyed in the format 1133 defined above. 1135 Actions of the receiver: 1137 The server extracts the client's signature from the CertificateVerify 1138 message, and verifies the signature using the public key it received 1139 in the client's Certificate message. 1141 5.9 Elliptic Curve Certificates 1143 X509 certificates containing ECC public keys or signed using ECDSA 1144 MUST comply with [11] or another RFC that replaces or extends it. 1145 Clients SHOULD use the elliptic curve domain parameters recommended 1146 in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. 1148 5.10 ECDH, ECDSA and RSA Computations 1150 All ECDH calculations (including parameter and key generation as well 1151 as the shared secret calculation) are performed according to [5] 1152 using the ECKAS-DH1 scheme with the identity map as key derivation 1153 function, so that the premaster secret is the x-coordinate of the 1154 ECDH shared secret elliptic curve point represented as an octet 1155 string. Note that this octet string (Z in IEEE 1363 terminology) as 1156 output by FE2OSP, the Field Element to Octet String Conversion 1157 Primitive, has constant length for any given field; leading zeros 1158 found in this octet string MUST NOT be truncated. 1160 Note that a new extension may be introduced in the future to allow 1161 the use of a different KDF during computation of the premaster 1162 secret. In this event, the new KDF would be used in place of the 1163 process detailed above. This may be desirable, for example, to 1164 support compatibility with the planned NIST key agreement standard. 1166 All ECDSA computations MUST be performed according to ANSI X9.62 [6] 1167 or its successors. Data to be signed/verified is hashed and the 1168 result run directly through the ECDSA algorithm with no additional 1169 hashing. The default hash function is SHA-1 [7] and sha_size (see 1170 Section 5.4 and Section 5.8) is 20. However, an alternative hash 1171 function, such as one of the new SHA hash functions specified in FIPS 1172 180-2 [7], may be used instead if the certificate containing the EC 1173 public key explicitly requires use of another hash function. (The 1174 mechanism for specifying the required hash function has not been 1175 standardized but this provision anticipates such standardization and 1176 obviates the need to update this document in response. Future PKIX 1177 RFCs may choose, for example, to specify the hash function to be used 1178 with a public key in the parameters field of subjectPublicKeyInfo.) 1180 All RSA signatures must be generated and verified according to PKCS#1 1181 [9] block type 1. 1183 6. Cipher Suites 1185 The table below defines new ECC cipher suites that use the key 1186 exchange algorithms specified in Section 2. 1188 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1189 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1190 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } 1191 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1192 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1193 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1195 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1196 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1197 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1198 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1199 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1201 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1202 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1203 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1204 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1205 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1207 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1208 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1209 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1210 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1211 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1213 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } 1214 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } 1215 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1216 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1217 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1219 Table 5: TLS ECC cipher suites 1221 [[ EDITOR: The actual cipher suite numbers will be assigned when this 1222 draft progresses to RFC. ]] 1224 The key exchange method, cipher, and hash algorithm for each of these 1225 cipher suites are easily determined by examining the name. Ciphers 1226 other than AES ciphers, and hash algorithms are defined in [2]. AES 1227 ciphers are defined in [16]. 1229 Server implementations SHOULD support all of the following cipher 1230 suites, and client implementations SHOULD support at least one of 1231 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 1232 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 1233 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 1234 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 1236 7. Security Considerations 1238 This document is based on [2], [5], [6] and [16]. The appropriate 1239 security considerations of those documents apply. 1241 One important issue that implementors and users must consider is 1242 elliptic curve selection. Guidance on selecting an appropriate 1243 elliptic curve size is given in Table 1. 1245 Beyond elliptic curve size, the main issue is elliptic curve 1246 structure. As a general principle, it is more conservative to use 1247 elliptic curves with as little algebraic structure as possible - thus 1248 random curves are more conservative than special curves such as 1249 Koblitz curves, and curves over F_p with p random are more 1250 conservative than curves over F_p with p of a special form (and 1251 curves over F_p with p random might be considered more conservative 1252 than curves over F_2^m as there is no choice between multiple fields 1253 of similar size for characteristic 2). Note, however, that algebraic 1254 structure can also lead to implementation efficiencies and 1255 implementors and users may, therefore, need to balance conservatism 1256 against a need for efficiency. Concrete attacks are known against 1257 only very few special classes of curves, such as supersingular 1258 curves, and these classes are excluded from the ECC standards that 1259 this document references [5], [6]. 1261 Another issue is the potential for catastrophic failures when a 1262 single elliptic curve is widely used. In this case, an attack on the 1263 elliptic curve might result in the compromise of a large number of 1264 keys. Again, this concern may need to be balanced against efficiency 1265 and interoperability improvements associated with widely-used curves. 1266 Substantial additional information on elliptic curve choice can be 1267 found in [4], [5], [6], [8]. 1269 Implementors and users must also consider whether they need forward 1270 secrecy. Forward secrecy refers to the property that session keys 1271 are not compromised if the static, certified keys belonging to the 1272 server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key 1273 exchange algorithms provide forward secrecy protection in the event 1274 of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. 1275 Similarly if the client is providing a static, certified key, 1276 ECDSA_sign client authentication provides forward secrecy protection 1277 in the event of client key compromise, while ECDSA_fixed_ECDH and 1278 RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy 1279 protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, 1280 with ECDSA_sign used for client authentication if necessary. Here 1281 again the security benefits of forward secrecy may need to be 1282 balanced against the improved efficiency offered by other options. 1284 8. IANA Considerations 1286 This document describes three new name spaces for use with the TLS 1287 protocol: 1289 o NamedCurve (Section 5.1) 1291 o ECPointFormat (Section 5.1) 1293 o ECCurveType (Section 5.4) 1295 For each name space, this document defines the initial value 1296 assignments and defines a range of 256 values (NamedCurve) or eight 1297 values (ECPointFormat and ECCurveType) reserved for Private Use. Any 1298 additional assignments require IETF Consensus action [12]. 1300 9. Acknowledgments 1302 The authors wish to thank Bill Anderson and Tim Dierks. 1304 10. References 1306 10.1 Normative References 1308 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 1309 Levels", RFC 2119, March 1997. 1311 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1312 RFC 2246, January 1999. 1314 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and 1315 T. Wright, "Transport Layer Security (TLS) Extensions", 1316 draft-ietf-tls-rfc3546bis-01.txt (work in progress), May 2005. 1318 [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, 1319 . 1321 [5] IEEE, "Standard Specifications for Public Key Cryptography", 1322 IEEE 1363, 2000. 1324 [6] ANSI, "Public Key Cryptography For The Financial Services 1325 Industry: The Elliptic Curve Digital Signature Algorithm 1326 (ECDSA)", ANSI X9.62, 1998. 1328 [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 1330 [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1332 [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1333 1.5", PKCS 1, November 1993. 1335 [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 1336 2000, . 1338 [11] Polk, T., Housley, R., and L. Bassham, "Algorithms and 1339 Identifiers for the Internet X.509 Public Key Infrastructure 1340 Certificate and Certificate Revocation List (CRL) Profile", 1341 RFC 3279, April 2002. 1343 [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1344 Considerations Section in RFCs", RFC 2434, October 1998. 1346 10.2 Informative References 1348 [13] Harper, G., Menezes, A., and S. Vanstone, "Public-Key 1349 Cryptosystems with Very Small Key Lengths", Advances in 1350 Cryptology -- EUROCRYPT '92, LNCS 658, 1993. 1352 [14] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1353 Sizes", Journal of Cryptology 14 (2001) 255-293, 1354 . 1356 [15] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1357 Version 3.0", November 1996, 1358 . 1360 [16] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1361 Transport Layer Security (TLS)", RFC 3268, June 2002. 1363 Authors' Addresses 1365 Vipul Gupta 1366 Sun Microsystems Laboratories 1367 16 Network Circle 1368 MS UMPK16-160 1369 Menlo Park, CA 94025 1370 US 1372 Phone: +1 650 786 7551 1373 Email: vipul.gupta@sun.com 1375 Simon Blake-Wilson 1376 Basic Commerce & Industries, Inc. 1377 96 Spandia Ave 1378 Unit 606 1379 Toronto, ON M6G 2T6 1380 CA 1382 Phone: +1 416 214 5961 1383 Email: sblakewilson@bcisse.com 1385 Bodo Moeller 1386 University of Calgary 1387 Dept of Math & Stats 1388 2500 University Dr NW 1389 Calgary, AB T2N 1N4 1390 CA 1392 Phone: +1 403 220 5735 1393 Email: bodo@openssl.org 1394 Chris Hawk 1395 Corriente Networks 1397 Email: chris@corriente.net 1399 Nelson Bolyard 1401 Email: nelson@bolyard.com 1403 Intellectual Property Statement 1405 The IETF takes no position regarding the validity or scope of any 1406 Intellectual Property Rights or other rights that might be claimed to 1407 pertain to the implementation or use of the technology described in 1408 this document or the extent to which any license under such rights 1409 might or might not be available; nor does it represent that it has 1410 made any independent effort to identify any such rights. Information 1411 on the procedures with respect to rights in RFC documents can be 1412 found in BCP 78 and BCP 79. 1414 Copies of IPR disclosures made to the IETF Secretariat and any 1415 assurances of licenses to be made available, or the result of an 1416 attempt made to obtain a general license or permission for the use of 1417 such proprietary rights by implementers or users of this 1418 specification can be obtained from the IETF on-line IPR repository at 1419 http://www.ietf.org/ipr. 1421 The IETF invites any interested party to bring to its attention any 1422 copyrights, patents or patent applications, or other proprietary 1423 rights that may cover technology that may be required to implement 1424 this standard. Please address the information to the IETF at 1425 ietf-ipr@ietf.org. 1427 Disclaimer of Validity 1429 This document and the information contained herein are provided on an 1430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1432 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1433 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1434 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1437 Copyright Statement 1439 Copyright (C) The Internet Society (2005). This document is subject 1440 to the rights, licenses and restrictions contained in BCP 78, and 1441 except as set forth therein, the authors retain all their rights. 1443 Acknowledgment 1445 Funding for the RFC Editor function is currently provided by the 1446 Internet Society.