idnits 2.17.1 draft-ietf-tls-rfc4492bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4492, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 685 has weird spacing: '...rveType cur...' == Line 701 has weird spacing: '...ameters cur...' == Line 721 has weird spacing: '...HParams par...' -- The document date (March 22, 2016) is 2950 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) == Missing Reference: 'ChangeCipherSpec' is mentioned on line 210, but not defined == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-eddsa-00 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-eddsa (ref. 'CFRG-EdDSA') -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' == Outdated reference: A later version (-04) exists of draft-josefsson-pkix-eddsa-03 ** Downref: Normative reference to an Informational draft: draft-josefsson-pkix-eddsa (ref. 'PKIX-EdDSA') ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 7748 -- Possible downref: Non-RFC (?) normative reference: ref. 'SECG-SEC2' == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-02 -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Y. Nir 3 Internet-Draft Check Point 4 Obsoletes: 4492 (if approved) S. Josefsson 5 Intended status: Standards Track SJD AB 6 Expires: September 23, 2016 M. Pegourie-Gonnard 7 Independent / PolarSSL 8 March 22, 2016 10 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer 11 Security (TLS) Versions 1.2 and Earlier 12 draft-ietf-tls-rfc4492bis-07 14 Abstract 16 This document describes key exchange algorithms based on Elliptic 17 Curve Cryptography (ECC) for the Transport Layer Security (TLS) 18 protocol. In particular, it specifies the use of Ephemeral Elliptic 19 Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the 20 use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards 21 Digital Signature Algorithm (EdDSA) as new authentication mechanisms. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 23, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 59 2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 4 60 2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 7 64 3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 7 66 5. Data Structures and Computations . . . . . . . . . . . . . . 8 67 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8 68 5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 10 69 5.1.2. Supported Point Formats Extension . . . . . . . . . . 11 70 5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 12 71 5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 13 72 5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 14 73 5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 17 74 5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 18 75 5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 19 76 5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 21 77 5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 22 78 5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 22 79 5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 23 80 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 24 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 84 10. Version History for This Draft . . . . . . . . . . . . . . . 27 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 87 11.2. Informative References . . . . . . . . . . . . . . . . . 29 88 Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 30 89 Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 30 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 92 1. Introduction 94 Elliptic Curve Cryptography (ECC) has emerged as an attractive 95 public-key cryptosystem, in particular for mobile (i.e., wireless) 96 environments. Compared to currently prevalent cryptosystems such as 97 RSA, ECC offers equivalent security with smaller key sizes. This is 98 illustrated in the following table, based on [Lenstra_Verheul], which 99 gives approximate comparable key sizes for symmetric- and asymmetric- 100 key cryptosystems based on the best-known algorithms for attacking 101 them. 103 +-----------+-------+------------+ 104 | Symmetric | ECC | DH/DSA/RSA | 105 +-----------+-------+------------+ 106 | 80 | >=158 | 1024 | 107 | 112 | >=221 | 2048 | 108 | 128 | >=252 | 3072 | 109 | 192 | >=379 | 7680 | 110 | 256 | >=506 | 15360 | 111 +-----------+-------+------------+ 113 Table 1: Comparable Key Sizes (in bits) 115 Smaller key sizes result in savings for power, memory, bandwidth, and 116 computational cost that make ECC especially attractive for 117 constrained environments. 119 This document describes additions to TLS to support ECC, applicable 120 to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246]. The 121 use of ECC in TLS 1.3 is defined in [I-D.ietf-tls-tls13], and is 122 explicitly out of scope for this document. In particular, this 123 document defines: 125 o the use of the Elliptic Curve Diffie-Hellman key agreement scheme 126 with ephemeral keys to establish the TLS premaster secret, and 127 o the use of ECDSA certificates for authentication of 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 136 those messages. Section 6 defines 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's predecessor. Section 9 gives 141 acknowledgements. Appendix B provides differences from [RFC4492], 142 the document that this one replaces. 144 Implementation of this specification requires familiarity with TLS, 145 TLS extensions [RFC4366], and ECC (TBD: reference Wikipedia here?). 147 1.1. Conventions Used in This Document 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 2. Key Exchange Algorithm 155 This document defines three new ECC-based key exchange algorithms for 156 TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS 157 premaster secret, and they differ only in the mechanism (if any) used 158 to authenticate them. The derivation of the TLS master secret from 159 the premaster secret and the subsequent generation of bulk 160 encryption/MAC keys and initialization vectors is independent of the 161 key exchange algorithm and not impacted by the introduction of ECC. 163 Table 2 summarizes the new key exchange algorithms. All of these key 164 exchange algorithms provide forward secrecy. 166 +-------------+------------------------------------------------+ 167 | Algorithm | Description | 168 +-------------+------------------------------------------------+ 169 | ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. | 170 | ECDHE_RSA | Ephemeral ECDH with RSA signatures. | 171 | ECDH_anon | Anonymous ephemeral ECDH, no signatures. | 172 +-------------+------------------------------------------------+ 174 Table 2: ECC Key Exchange Algorithms 176 These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, 177 respectively. 179 With ECDHE_RSA, a server can reuse its existing RSA certificate and 180 easily comply with a constrained client's elliptic curve preferences 181 (see Section 4). However, the computational cost incurred by a 182 server is higher for ECDHE_RSA than for the traditional RSA key 183 exchange, which does not provide forward secrecy. 185 The anonymous key exchange algorithm does not provide authentication 186 of the server or the client. Like other anonymous TLS key exchanges, 187 it is subject to man-in-the-middle attacks. Implementations of this 188 algorithm SHOULD provide authentication by other means. 190 Note that there is no structural difference between ECDH and ECDSA 191 keys. A certificate issuer may use X.509 v3 keyUsage and 192 extendedKeyUsage extensions to restrict the use of an ECC public key 193 to certain computations. This document refers to an ECC key as ECDH- 194 capable if its use in ECDH is permitted. ECDSA-capable and EdDSA- 195 capable are defined similarly. 197 Client Server 198 ------ ------ 199 ClientHello --------> 200 ServerHello 201 Certificate* 202 ServerKeyExchange* 203 CertificateRequest*+ 204 <-------- ServerHelloDone 205 Certificate*+ 206 ClientKeyExchange 207 CertificateVerify*+ 208 [ChangeCipherSpec] 209 Finished --------> 210 [ChangeCipherSpec] 211 <-------- Finished 212 Application Data <-------> Application Data 213 * message is not sent under some conditions 214 + message is not sent unless client authentication 215 is desired 217 Figure 1: Message flow in a full TLS 1.2 handshake 219 Figure 1 shows all messages involved in the TLS key establishment 220 protocol (aka full handshake). The addition of ECC has direct impact 221 only on the ClientHello, the ServerHello, the server's Certificate 222 message, the ServerKeyExchange, the ClientKeyExchange, the 223 CertificateRequest, the client's Certificate message, and the 224 CertificateVerify. Next, we describe the ECC key exchange algorithm 225 in greater detail in terms of the content and processing of these 226 messages. For ease of exposition, we defer discussion of client 227 authentication and associated messages (identified with a + in 228 Figure 1) until Section 3 and of the optional ECC-specific extensions 229 (which impact the Hello messages) until Section 4. 231 2.1. ECDHE_ECDSA 233 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- or 234 EdDSA-capable public key. 236 The server sends its ephemeral ECDH public key and a specification of 237 the corresponding curve in the ServerKeyExchange message. These 238 parameters MUST be signed with ECDSA or EdDSA using the private key 239 corresponding to the public key in the server's Certificate. 241 The client generates an ECDH key pair on the same curve as the 242 server's ephemeral ECDH key and sends its public key in the 243 ClientKeyExchange message. 245 Both client and server perform an ECDH operation Section 5.10 and use 246 the resultant shared secret as the premaster secret. 248 2.2. ECDHE_RSA 250 This key exchange algorithm is the same as ECDHE_ECDSA except that 251 the server's certificate MUST contain an RSA public key authorized 252 for signing, and that the signature in the ServerKeyExchange message 253 must be computed with the corresponding RSA private key. 255 2.3. ECDH_anon 257 NOTE: Despite the name beginning with "ECDH_" (no E), the key used in 258 ECDH_anon is ephemeral just like the key in ECDHE_RSA and 259 ECDHE_ECDSA. The naming follows the example of DH_anon, where the 260 key is also ephemeral but the name does not reflect it. TBD: Do we 261 want to rename this so that it makes sense? 263 In ECDH_anon, the server's Certificate, the CertificateRequest, the 264 client's Certificate, and the CertificateVerify messages MUST NOT be 265 sent. 267 The server MUST send an ephemeral ECDH public key and a specification 268 of the corresponding curve in the ServerKeyExchange message. These 269 parameters MUST NOT be signed. 271 The client generates an ECDH key pair on the same curve as the 272 server's ephemeral ECDH key and sends its public key in the 273 ClientKeyExchange message. 275 Both client and server perform an ECDH operation and use the 276 resultant shared secret as the premaster secret. All ECDH 277 calculations are performed as specified in Section 5.10. 279 This specification does not impose restrictions on signature schemes 280 used anywhere in the certificate chain. The previous version of this 281 document required the signatures to match, but this restriction, 282 originating in previous TLS versions is lifted here as it had been in 283 RFC 5246. 285 3. Client Authentication 287 This document defines a client authentication mechanism, named after 288 the type of client certificate involved: ECDSA_sign. The ECDSA_sign 289 mechanism is usable with any of the non-anonymous ECC key exchange 290 algorithms described in Section 2 as well as other non-anonymous 291 (non-ECC) key exchange algorithms defined in TLS. 293 The server can request ECC-based client authentication by including 294 this certificate type in its CertificateRequest message. The client 295 must check if it possesses a certificate appropriate for the method 296 suggested by the server and is willing to use it for authentication. 298 If these conditions are not met, the client should send a client 299 Certificate message containing no certificates. In this case, the 300 ClientKeyExchange should be sent as described in Section 2, and the 301 CertificateVerify should not be sent. If the server requires client 302 authentication, it may respond with a fatal handshake failure alert. 304 If the client has an appropriate certificate and is willing to use it 305 for authentication, it must send that certificate in the client's 306 Certificate message (as per Section 5.6) and prove possession of the 307 private key corresponding to the certified key. The process of 308 determining an appropriate certificate and proving possession is 309 different for each authentication mechanism and described below. 311 NOTE: It is permissible for a server to request (and the client to 312 send) a client certificate of a different type than the server 313 certificate. 315 3.1. ECDSA_sign 317 To use this authentication mechanism, the client MUST possess a 318 certificate containing an ECDSA- or EdDSA-capable public key. 320 The client proves possession of the private key corresponding to the 321 certified key by including a signature in the CertificateVerify 322 message as described in Section 5.8. 324 4. TLS Extensions for ECC 326 Two new TLS extensions are defined in this specification: (i) the 327 Supported Elliptic Curves Extension, and (ii) the Supported Point 328 Formats Extension. These allow negotiating the use of specific 329 curves and point formats (e.g., compressed vs. uncompressed, 330 respectively) during a handshake starting a new session. These 331 extensions are especially relevant for constrained clients that may 332 only support a limited number of curves or point formats. They 333 follow the general approach outlined in [RFC4366]; message details 334 are specified in Section 5. The client enumerates the curves it 335 supports and the point formats it can parse by including the 336 appropriate extensions in its ClientHello message. The server 337 similarly enumerates the point formats it can parse by including an 338 extension in its ServerHello message. 340 A TLS client that proposes ECC cipher suites in its ClientHello 341 message SHOULD include these extensions. Servers implementing ECC 342 cipher suites MUST support these extensions, and when a client uses 343 these extensions, servers MUST NOT negotiate the use of an ECC cipher 344 suite unless they can complete the handshake while respecting the 345 choice of curves and compression techniques specified by the client. 346 This eliminates the possibility that a negotiated ECC handshake will 347 be subsequently aborted due to a client's inability to deal with the 348 server's EC key. 350 The client MUST NOT include these extensions in the ClientHello 351 message if it does not propose any ECC cipher suites. A client that 352 proposes ECC cipher suites may choose not to include these 353 extensions. In this case, the server is free to choose any one of 354 the elliptic curves or point formats listed in Section 5. That 355 section also describes the structure and processing of these 356 extensions in greater detail. 358 In the case of session resumption, the server simply ignores the 359 Supported Elliptic Curves Extension and the Supported Point Formats 360 Extension appearing in the current ClientHello message. These 361 extensions only play a role during handshakes negotiating a new 362 session. 364 5. Data Structures and Computations 366 This section specifies the data structures and computations used by 367 ECC-based key mechanisms specified in the previous three sections. 368 The presentation language used here is the same as that used in TLS. 369 Since this specification extends TLS, these descriptions should be 370 merged with those in the TLS specification and any others that extend 371 TLS. This means that enum types may not specify all possible values, 372 and structures with multiple formats chosen with a select() clause 373 may not indicate all possible cases. 375 5.1. Client Hello Extensions 377 This section specifies two TLS extensions that can be included with 378 the ClientHello message as described in [RFC4366], the Supported 379 Elliptic Curves Extension and the Supported Point Formats Extension. 381 When these extensions are sent: 383 The extensions SHOULD be sent along with any ClientHello message that 384 proposes ECC cipher suites. 386 Meaning of these extensions: 388 These extensions allow a client to enumerate the elliptic curves it 389 supports and/or the point formats it can parse. 391 Structure of these extensions: 393 The general structure of TLS extensions is described in [RFC4366], 394 and this specification adds two new types to ExtensionType. 396 enum { 397 elliptic_curves(10), 398 ec_point_formats(11) 399 } ExtensionType; 401 elliptic_curves (Supported Elliptic Curves Extension): Indicates the 402 set of elliptic curves supported by the client. For this 403 extension, the opaque extension_data field contains 404 EllipticCurveList. See Section 5.1.1 for details. 405 ec_point_formats (Supported Point Formats Extension): Indicates the 406 set of point formats that the client can parse. For this 407 extension, the opaque extension_data field contains 408 ECPointFormatList. See Section 5.1.2 for details. 410 Actions of the sender: 412 A client that proposes ECC cipher suites in its ClientHello message 413 appends these extensions (along with any others), enumerating the 414 curves it supports and the point formats it can parse. Clients 415 SHOULD send both the Supported Elliptic Curves Extension and the 416 Supported Point Formats Extension. If the Supported Point Formats 417 Extension is indeed sent, it MUST contain the value 0 (uncompressed) 418 as one of the items in the list of point formats. 420 Actions of the receiver: 422 A server that receives a ClientHello containing one or both of these 423 extensions MUST use the client's enumerated capabilities to guide its 424 selection of an appropriate cipher suite. One of the proposed ECC 425 cipher suites must be negotiated only if the server can successfully 426 complete the handshake while using the curves and point formats 427 supported by the client (cf. Section 5.3 and Section 5.4). 429 NOTE: A server participating in an ECDHE_ECDSA key exchange may use 430 different curves for the ECDSA or EdDSA key in its certificate, and 431 for the ephemeral ECDH key in the ServerKeyExchange message. The 432 server MUST consider the extensions in both cases. 434 If a server does not understand the Supported Elliptic Curves 435 Extension, does not understand the Supported Point Formats Extension, 436 or is unable to complete the ECC handshake while restricting itself 437 to the enumerated curves and point formats, it MUST NOT negotiate the 438 use of an ECC cipher suite. Depending on what other cipher suites 439 are proposed by the client and supported by the server, this may 440 result in a fatal handshake failure alert due to the lack of common 441 cipher suites. 443 5.1.1. Supported Elliptic Curves Extension 445 RFC 4492 defined 25 different curves in the NamedCurve registry (now 446 renamed the "Supported Groups" registry, although the enumeration 447 below is still named NamedCurve) for use in TLS. Only three have 448 seen much use. This specification is deprecating the rest (with 449 numbers 1-22). This specification also deprecates the explicit 450 curves with identifiers 0xFF01 and 0xFF02. It also adds the new 451 curves defined in [RFC7748] and [CFRG-EdDSA]. The end result is as 452 follows: 454 enum { 455 deprecated(1..22), 456 secp256r1 (23), secp384r1 (24), secp521r1 (25), 457 ecdh_x25519(29), ecdh_x448(30), 458 eddsa_ed25519(TBD3), eddsa_ed448(TBD4), 459 reserved (0xFE00..0xFEFF), 460 deprecated(0xFF01..0xFF02), 461 (0xFFFF) 462 } NamedCurve; 464 Note that other specification have since added other values to this 465 enumeration. 467 secp256r1, etc: Indicates support of the corresponding named curve or 468 class of explicitly defined curves. The named curves secp256r1, 469 secp384r1, and secp521r1 are specified in SEC 2 [SECG-SEC2]. These 470 curves are also recommended in ANSI X9.62 [ANSI.X9-62.2005] and FIPS 471 186-4 [FIPS.186-4]. ecdh_x25519 and ecdh_x448 are defined in 472 [RFC7748]. eddsa_ed25519 and eddsa_ed448 are signature-only curves 473 defined in [CFRG-EdDSA]. Values 0xFE00 through 0xFEFF are reserved 474 for private use. 476 The NamedCurve name space is maintained by IANA. See Section 8 for 477 information on how new value assignments are added. 479 struct { 480 NamedCurve elliptic_curve_list<2..2^16-1> 481 } EllipticCurveList; 483 Items in elliptic_curve_list are ordered according to the client's 484 preferences (favorite choice first). 486 As an example, a client that only supports secp256r1 (aka NIST P-256; 487 value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) 488 and prefers to use secp256r1 would include a TLS extension consisting 489 of the following octets. Note that the first two octets indicate the 490 extension type (Supported Elliptic Curves Extension): 492 00 0A 00 06 00 04 00 17 00 18 494 5.1.2. Supported Point Formats Extension 496 enum { 497 uncompressed (0), 498 ansiX962_compressed_prime (1), 499 ansiX962_compressed_char2 (2), 500 reserved (248..255) 501 } ECPointFormat; 502 struct { 503 ECPointFormat ec_point_format_list<1..2^8-1> 504 } ECPointFormatList; 506 Three point formats were included in the definition of ECPointFormat 507 above. This specification deprecates all but the uncompressed point 508 format. Implementations of this document MUST support the 509 uncompressed format for all of their supported curves, and MUST NOT 510 support other formats for curves defined in this specification. For 511 backwards compatibility purposes, the point format list extension 512 MUST still be included, and contain exactly one value: the 513 uncompressed point format (0). 515 The ECPointFormat name space is maintained by IANA. See Section 8 516 for information on how new value assignments are added. 518 Items in ec_point_format_list are ordered according to the client's 519 preferences (favorite choice first). 521 A client compliant with this specification that supports no other 522 curves MUST send the following octets; note that the first two octets 523 indicate the extension type (Supported Point Formats Extension): 525 00 0B 00 02 01 00 527 5.2. Server Hello Extension 529 This section specifies a TLS extension that can be included with the 530 ServerHello message as described in [RFC4366], the Supported Point 531 Formats Extension. 533 When this extension is sent: 535 The Supported Point Formats Extension is included in a ServerHello 536 message in response to a ClientHello message containing the Supported 537 Point Formats Extension when negotiating an ECC cipher suite. 539 Meaning of this extension: 541 This extension allows a server to enumerate the point formats it can 542 parse (for the curve that will appear in its ServerKeyExchange 543 message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key 544 exchange algorithm. 546 Structure of this extension: 548 The server's Supported Point Formats Extension has the same structure 549 as the client's Supported Point Formats Extension (see 550 Section 5.1.2). Items in ec_point_format_list here are ordered 551 according to the server's preference (favorite choice first). Note 552 that the server may include items that were not found in the client's 553 list (e.g., the server may prefer to receive points in compressed 554 format even when a client cannot parse this format: the same client 555 may nevertheless be capable of outputting points in compressed 556 format). 558 Actions of the sender: 560 A server that selects an ECC cipher suite in response to a 561 ClientHello message including a Supported Point Formats Extension 562 appends this extension (along with others) to its ServerHello 563 message, enumerating the point formats it can parse. The Supported 564 Point Formats Extension, when used, MUST contain the value 0 565 (uncompressed) as one of the items in the list of point formats. 567 Actions of the receiver: 569 A client that receives a ServerHello message containing a Supported 570 Point Formats Extension MUST respect the server's choice of point 571 formats during the handshake (cf. Section 5.6 and Section 5.7). If 572 no Supported Point Formats Extension is received with the 573 ServerHello, this is equivalent to an extension allowing only the 574 uncompressed point format. 576 5.3. Server Certificate 578 When this message is sent: 580 This message is sent in all non-anonymous ECC-based key exchange 581 algorithms. 583 Meaning of this message: 585 This message is used to authentically convey the server's static 586 public key to the client. The following table shows the server 587 certificate type appropriate for each key exchange algorithm. ECC 588 public keys MUST be encoded in certificates as described in 589 Section 5.9. 591 NOTE: The server's Certificate message is capable of carrying a chain 592 of certificates. The restrictions mentioned in Table 3 apply only to 593 the server's certificate (first in the chain). 595 +-------------+-----------------------------------------------------+ 596 | Algorithm | Server Certificate Type | 597 +-------------+-----------------------------------------------------+ 598 | ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable | 599 | | public key. | 600 | ECDHE_RSA | Certificate MUST contain an RSA public key | 601 | | authorized for use in digital signatures. | 602 +-------------+-----------------------------------------------------+ 604 Table 3: Server Certificate Types 606 Structure of this message: 608 Identical to the TLS Certificate format. 610 Actions of the sender: 612 The server constructs an appropriate certificate chain and conveys it 613 to the client in the Certificate message. If the client has used a 614 Supported Elliptic Curves Extension, the public key in the server's 615 certificate MUST respect the client's choice of elliptic curves; in 616 particular, the public key MUST employ a named curve (not the same 617 curve as an explicit curve) unless the client has indicated support 618 for explicit curves of the appropriate type. If the client has used 619 a Supported Point Formats Extension, both the server's public key 620 point and (in the case of an explicit curve) the curve's base point 621 MUST respect the client's choice of point formats. (A server that 622 cannot satisfy these requirements MUST NOT choose an ECC cipher suite 623 in its ServerHello message.) 625 Actions of the receiver: 627 The client validates the certificate chain, extracts the server's 628 public key, and checks that the key type is appropriate for the 629 negotiated key exchange algorithm. (A possible reason for a fatal 630 handshake failure is that the client's capabilities for handling 631 elliptic curves and point formats are exceeded; cf. Section 5.1.) 633 5.4. Server Key Exchange 635 When this message is sent: 637 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and 638 ECDH_anon key exchange algorithms. 640 Meaning of this message: 642 This message is used to convey the server's ephemeral ECDH public key 643 (and the corresponding elliptic curve domain parameters) to the 644 client. 646 The ECCCurveType enum used to have values for explicit prime and for 647 explicit char2 curves. Those values are now deprecated, so only one 648 value remains: 650 Structure of this message: 652 enum { 653 deprecated (1..2), 654 named_curve (3), 655 reserved(248..255) 656 } ECCurveType; 658 The value named_curve indicates that a named curve is used. This 659 option SHOULD be used when applicable. 661 Values 248 through 255 are reserved for private use. 663 The ECCurveType name space is maintained by IANA. See Section 8 for 664 information on how new value assignments are added. 666 RFC 4492 had a specification for an ECCurve structure and an 667 ECBasisType structure. Both of these are omitted now because they 668 were only used with the now deprecated explicit curves. 670 struct { 671 opaque point <1..2^8-1>; 672 } ECPoint; 674 This is the byte string representation of an elliptic curve point 675 following the conversion routine in Section 4.3.6 of 676 [ANSI.X9-62.2005]. This byte string may represent an elliptic curve 677 point in uncompressed or compressed format; it MUST conform to what 678 the client has requested through a Supported Point Formats Extension 679 if this extension was used. For the X25519 and X448 curves, the only 680 valid representation is the one specified in [RFC7748] - a 32- or 681 56-octet representation of the u value of the point. This structure 682 MUST NOT be used with Ed25519 and Ed448 public keys. 684 struct { 685 ECCurveType curve_type; 686 select (curve_type) { 687 case named_curve: 688 NamedCurve namedcurve; 689 }; 690 } ECParameters; 692 This identifies the type of the elliptic curve domain parameters. 694 Specifies a recommended set of elliptic curve domain parameters. All 695 those values of NamedCurve are allowed that refer to a curve capable 696 of Diffie-Hellman. With the deprecation of the explicit curves, this 697 now includes all values of NamedCurve except eddsa_ed25519(TBD3) and 698 eddsa_ed448(TBD4). 700 struct { 701 ECParameters curve_params; 702 ECPoint public; 703 } ServerECDHParams; 705 Specifies the elliptic curve domain parameters associated with the 706 ECDH public key. 708 The ephemeral ECDH public key. 710 The ServerKeyExchange message is extended as follows. 712 enum { 713 ec_diffie_hellman 714 } KeyExchangeAlgorithm; 716 ec_diffie_hellman: Indicates the ServerKeyExchange message contains 717 an ECDH public key. 719 select (KeyExchangeAlgorithm) { 720 case ec_diffie_hellman: 721 ServerECDHParams params; 722 Signature signed_params; 723 } ServerKeyExchange; 725 params: Specifies the ECDH public key and associated domain 726 parameters. 727 signed_params: A hash of the params, with the signature appropriate 728 to that hash applied. The private key corresponding to the 729 certified public key in the server's Certificate message is used 730 for signing. 732 enum { 733 ecdsa(3), 734 eddsa(TBD5) 735 } SignatureAlgorithm; 736 select (SignatureAlgorithm) { 737 case ecdsa: 738 digitally-signed struct { 739 opaque sha_hash[sha_size]; 740 }; 741 case eddsa: 742 digitally-signed struct { 743 opaque rawdata[rawdata_size]; 744 }; 745 } Signature; 746 ServerKeyExchange.signed_params.sha_hash 747 SHA(ClientHello.random + ServerHello.random + 748 ServerKeyExchange.params); 749 ServerKeyExchange.signed_params.rawdata 750 ClientHello.random + ServerHello.random + 751 ServerKeyExchange.params; 753 NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange 754 algorithm and "anonymous" for ECDH_anon. These cases are defined in 755 TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA. 756 ECDSA signatures are generated and verified as described in 757 Section 5.10, and SHA in the above template for sha_hash accordingly 758 may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an 759 ECDSA signature consists of a pair of integers, r and s. The 760 digitally-signed element is encoded as an opaque vector <0..2^16-1>, 761 the contents of which are the DER encoding corresponding to the 762 following ASN.1 notation. 764 Ecdsa-Sig-Value ::= SEQUENCE { 765 r INTEGER, 766 s INTEGER 767 } 769 EdDSA signatures are generated and verified according to 770 [CFRG-EdDSA]. The digitally-signed element is encoded as an opaque 771 vector<0..2^16-1>, the contents of which is the octet string output 772 of the EdDSA signing algorithm. 774 Actions of the sender: 776 The server selects elliptic curve domain parameters and an ephemeral 777 ECDH public key corresponding to these parameters according to the 778 ECKAS-DH1 scheme from IEEE 1363 [IEEE.P1363.1998]. It conveys this 779 information to the client in the ServerKeyExchange message using the 780 format defined above. 782 Actions of the receiver: 784 The client verifies the signature (when present) and retrieves the 785 server's elliptic curve domain parameters and ephemeral ECDH public 786 key from the ServerKeyExchange message. (A possible reason for a 787 fatal handshake failure is that the client's capabilities for 788 handling elliptic curves and point formats are exceeded; cf. 789 Section 5.1.) 791 5.5. Certificate Request 793 When this message is sent: 795 This message is sent when requesting client authentication. 797 Meaning of this message: 799 The server uses this message to suggest acceptable client 800 authentication methods. 802 Structure of this message: 804 The TLS CertificateRequest message is extended as follows. 806 enum { 807 ecdsa_sign(64), 808 rsa_fixed_ecdh(65), 809 ecdsa_fixed_ecdh(66), 810 (255) 811 } ClientCertificateType; 813 ecdsa_sign, etc. Indicates that the server would like to use the 814 corresponding client authentication method specified in Section 3. 816 Actions of the sender: 818 The server decides which client authentication methods it would like 819 to use, and conveys this information to the client using the format 820 defined above. 822 Actions of the receiver: 824 The client determines whether it has a suitable certificate for use 825 with any of the requested methods and whether to proceed with client 826 authentication. 828 5.6. Client Certificate 830 When this message is sent: 832 This message is sent in response to a CertificateRequest when a 833 client has a suitable certificate and has decided to proceed with 834 client authentication. (Note that if the server has used a Supported 835 Point Formats Extension, a certificate can only be considered 836 suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and 837 ECDSA_fixed_ECDH authentication methods if the public key point 838 specified in it respects the server's choice of point formats. If no 839 Supported Point Formats Extension has been used, a certificate can 840 only be considered suitable for use with these authentication methods 841 if the point is represented in uncompressed point format.) 843 Meaning of this message: 845 This message is used to authentically convey the client's static 846 public key to the server. The following table summarizes what client 847 certificate types are appropriate for the ECC-based client 848 authentication mechanisms described in Section 3. ECC public keys 849 must be encoded in certificates as described in Section 5.9. 851 NOTE: The client's Certificate message is capable of carrying a chain 852 of certificates. The restrictions mentioned in Table 4 apply only to 853 the client's certificate (first in the chain). 855 +------------------+------------------------------------------------+ 856 | Client | Client Certificate Type | 857 | Authentication | | 858 | Method | | 859 +------------------+------------------------------------------------+ 860 | ECDSA_sign | Certificate MUST contain an ECDSA- or EdDSA- | 861 | | capable public key. | 862 | ECDSA_fixed_ECDH | Certificate MUST contain an ECDH-capable | 863 | | public key on the same elliptic curve as the | 864 | | server's long-term ECDH key. | 865 | RSA_fixed_ECDH | The same as ECDSA_fixed_ECDH. The codepoints | 866 | | meant different things, but due to changes in | 867 | | TLS 1.2, both mean the same thing now. | 868 +------------------+------------------------------------------------+ 870 Table 4: Client Certificate Types 872 Structure of this message: 874 Identical to the TLS client Certificate format. 876 Actions of the sender: 878 The client constructs an appropriate certificate chain, and conveys 879 it to the server in the Certificate message. 881 Actions of the receiver: 883 The TLS server validates the certificate chain, extracts the client's 884 public key, and checks that the key type is appropriate for the 885 client authentication method. 887 5.7. Client Key Exchange 889 When this message is sent: 891 This message is sent in all key exchange algorithms. If client 892 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 893 message is empty. Otherwise, it contains the client's ephemeral ECDH 894 public key. 896 Meaning of the message: 898 This message is used to convey ephemeral data relating to the key 899 exchange belonging to the client (such as its ephemeral ECDH public 900 key). 902 Structure of this message: 904 The TLS ClientKeyExchange message is extended as follows. 906 enum { 907 implicit, 908 explicit 909 } PublicValueEncoding; 911 implicit, explicit: For ECC cipher suites, this indicates whether 912 the client's ECDH public key is in the client's certificate 913 ("implicit") or is provided, as an ephemeral ECDH public key, in 914 the ClientKeyExchange message ("explicit"). (This is "explicit" 915 in ECC cipher suites except when the client uses the 916 ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication 917 mechanism.) 919 struct { 920 select (PublicValueEncoding) { 921 case implicit: struct { }; 922 case explicit: ECPoint ecdh_Yc; 923 } ecdh_public; 924 } ClientECDiffieHellmanPublic; 925 ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte 926 string ECPoint.point, which may represent an elliptic curve point 927 in uncompressed or compressed format. Curves eddsa_ed25519 and 928 eddsa_ed448 MUST NOT be used here. Here, the format MUST conform 929 to what the server has requested through a Supported Point Formats 930 Extension if this extension was used, and MUST be uncompressed if 931 this extension was not used. 933 struct { 934 select (KeyExchangeAlgorithm) { 935 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 936 } exchange_keys; 937 } ClientKeyExchange; 939 Actions of the sender: 941 The client selects an ephemeral ECDH public key corresponding to the 942 parameters it received from the server according to the ECKAS-DH1 943 scheme from IEEE 1363. It conveys this information to the client in 944 the ClientKeyExchange message using the format defined above. 946 Actions of the receiver: 948 The server retrieves the client's ephemeral ECDH public key from the 949 ClientKeyExchange message and checks that it is on the same elliptic 950 curve as the server's ECDH key. 952 5.8. Certificate Verify 954 When this message is sent: 956 This message is sent when the client sends a client certificate 957 containing a public key usable for digital signatures, e.g., when the 958 client is authenticated using the ECDSA_sign mechanism. 960 Meaning of the message: 962 This message contains a signature that proves possession of the 963 private key corresponding to the public key in the client's 964 Certificate message. 966 Structure of this message: 968 The TLS CertificateVerify message and the underlying Signature type 969 are defined in the TLS base specifications, and the latter is 970 extended here in Section 5.4. For the ecdsa and eddsa cases, the 971 signature field in the CertificateVerify message contains an ECDSA or 972 EdDSA (respectively) signature computed over handshake messages 973 exchanged so far, exactly similar to CertificateVerify with other 974 signing algorithms: 976 CertificateVerify.signature.sha_hash 977 SHA(handshake_messages); 978 CertificateVerify.signature.rawdata 979 handshake_messages; 981 ECDSA signatures are computed as described in Section 5.10, and SHA 982 in the above template for sha_hash accordingly may denote a hash 983 algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature 984 consists of a pair of integers, r and s. The digitally-signed 985 element is encoded as an opaque vector <0..2^16-1>, the contents of 986 which are the DER encoding [CCITT.X690] corresponding to the 987 following ASN.1 notation [CCITT.X680]. 989 Ecdsa-Sig-Value ::= SEQUENCE { 990 r INTEGER, 991 s INTEGER 992 } 994 EdDSA signatures are generated and verified according to 995 [CFRG-EdDSA]. The digitally-signed element is encoded as an opaque 996 vector<0..2^16-1>, the contents of which is the octet string output 997 of the EdDSA signing algorithm. 999 Actions of the sender: 1001 The client computes its signature over all handshake messages sent or 1002 received starting at client hello and up to but not including this 1003 message. It uses the private key corresponding to its certified 1004 public key to compute the signature, which is conveyed in the format 1005 defined above. 1007 Actions of the receiver: 1009 The server extracts the client's signature from the CertificateVerify 1010 message, and verifies the signature using the public key it received 1011 in the client's Certificate message. 1013 5.9. Elliptic Curve Certificates 1015 X.509 certificates containing ECC public keys or signed using ECDSA 1016 MUST comply with [RFC3279] or another RFC that replaces or extends 1017 it. X.509 certificates containing ECC public keys or signed using 1018 EdDSA MUST comply with [PKIX-EdDSA]. Clients SHOULD use the elliptic 1019 curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and 1020 SEC 2 [SECG-SEC2] or in [CFRG-EdDSA]. 1022 EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the 1023 eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the 1024 eddsa_ed448 curve. Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and 1025 eddsa_ed448 MUST NOT be used for ECDSA. 1027 5.10. ECDH, ECDSA, and RSA Computations 1029 All ECDH calculations for the NIST curves (including parameter and 1030 key generation as well as the shared secret calculation) are 1031 performed according to [IEEE.P1363.1998] using the ECKAS-DH1 scheme 1032 with the identity map as key derivation function (KDF), so that the 1033 premaster secret is the x-coordinate of the ECDH shared secret 1034 elliptic curve point represented as an octet string. Note that this 1035 octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the 1036 Field Element to Octet String Conversion Primitive, has constant 1037 length for any given field; leading zeros found in this octet string 1038 MUST NOT be truncated. 1040 (Note that this use of the identity KDF is a technicality. The 1041 complete picture is that ECDH is employed with a non-trivial KDF 1042 because TLS does not directly use the premaster secret for anything 1043 other than for computing the master secret. In TLS 1.0 and 1.1, this 1044 means that the MD5- and SHA-1-based TLS PRF serves as a KDF; in TLS 1045 1.2 the KDF is determined by ciphersuite; it is conceivable that 1046 future TLS versions or new TLS extensions introduced in the future 1047 may vary this computation.) 1048 An ECDHE key exchange using X25519 (curve ecdh_x25519) goes as 1049 follows: Each party picks a secret key d uniformly at random and 1050 computes the corresponding public key x = X25519(d, G). Parties 1051 exchange their public keys, and compute a shared secret as x_S = 1052 X25519(d, x_peer). If either party obtains all-zeroes x_S, it MUST 1053 abort the handshake (as required by definition of X25519 and X448). 1054 ECDHE for X448 works similarily, replacing X25519 with X448, and 1055 ecdh_x25519 with ecdh_x448. The derived shared secret is used 1056 directly as the premaster secret, which is always exactly 32 bytes 1057 when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is 1058 used. 1060 All ECDSA computations MUST be performed according to ANSI X9.62 or 1061 its successors. Data to be signed/verified is hashed, and the result 1062 run directly through the ECDSA algorithm with no additional hashing. 1063 The default hash function is SHA-1 [FIPS.180-2], and sha_size (see 1064 Section 5.4 and Section 5.8) is 20. However, an alternative hash 1065 function, such as one of the new SHA hash functions specified in FIPS 1066 180-2 [FIPS.180-2], SHOULD be used instead. 1068 All EdDSA computations MUST be performed according to [CFRG-EdDSA] or 1069 its succesors. Data to be signed/verified is run through the EdDSA 1070 algorithm wih no hashing (EdDSA will internally run the data through 1071 the PH function). 1073 RFC 4492 anticipated the standardization of a mechanism for 1074 specifying the required hash function in the certificate, perhaps in 1075 the parameters field of the subjectPublicKeyInfo. Such 1076 standardization never took place, and as a result, SHA-1 is used in 1077 TLS 1.1 and earlier (except for EdDSA, which uses identity function). 1078 TLS 1.2 added a SignatureAndHashAlgorithm parameter to the 1079 DigitallySigned struct, thus allowing agility in choosing the 1080 signature hash. EdDSA signatures MUST have HashAlgorithm of 0 1081 (None). 1083 All RSA signatures must be generated and verified according to 1084 [PKCS1] block type 1. 1086 5.11. Public Key Validation 1088 With the NIST curves, each party must validate the public key sent by 1089 its peer before performing cryptographic computations with it. 1090 Failing to do so allows attackers to gain information about the 1091 private key, to the point that they may recover the entire private 1092 key in a few requests, if that key is not really ephemeral. 1094 X25519 was designed in a way that the result of X25519(x, d) will 1095 never reveal information about d, provided it was chosen as 1096 prescribed, for any value of x (the same holds true for X448). 1098 All-zeroes output from X25519 or X448 MUST NOT be used for premaster 1099 secret (as required by definition of X25519 and X448). If the 1100 premaster secret would be all zeroes, the handshake MUST be aborted 1101 (most probably by sending a fatal alert). 1103 Let's define legitimate values of x as the values that can be 1104 obtained as x = X25519(G, d') for some d', and call the other values 1105 illegitimate. The definition of the X25519 function shows that 1106 legitimate values all share the following property: the high-order 1107 bit of the last byte is not set (for X448, any bit can be set). 1109 Since there are some implementation of the X25519 function that 1110 impose this restriction on their input and others that don't, 1111 implementations of X25519 in TLS SHOULD reject public keys when the 1112 high-order bit of the last byte is set (in other words, when the 1113 value of the leftmost byte is greater than 0x7F) in order to prevent 1114 implementation fingerprinting. 1116 Ed25519 and Ed448 internally do public key validation as part of 1117 signature verification. 1119 Other than this recommended check, implementations do not need to 1120 ensure that the public keys they receive are legitimate: this is not 1121 necessary for security with X25519. 1123 6. Cipher Suites 1125 The table below defines new ECC cipher suites that use the key 1126 exchange algorithms specified in Section 2. 1128 +---------------------------------------+----------------+ 1129 | CipherSuite | Identifier | 1130 +---------------------------------------+----------------+ 1131 | TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } | 1132 | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } | 1133 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } | 1134 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } | 1135 | | | 1136 | TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } | 1137 | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } | 1138 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } | 1139 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } | 1140 | | | 1141 | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } | 1142 | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } | 1143 | TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } | 1144 | TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } | 1145 +---------------------------------------+----------------+ 1147 Table 5: TLS ECC cipher suites 1149 The key exchange method, cipher, and hash algorithm for each of these 1150 cipher suites are easily determined by examining the name. Ciphers 1151 (other than AES ciphers) and hash algorithms are defined in [RFC2246] 1152 and [RFC4346]. AES ciphers are defined in [RFC5246]. 1154 Server implementations SHOULD support all of the following cipher 1155 suites, and client implementations SHOULD support at least one of 1156 them: 1158 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 1159 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 1160 o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 1161 o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 1163 7. Security Considerations 1165 Security issues are discussed throughout this memo. 1167 For TLS handshakes using ECC cipher suites, the security 1168 considerations in appendices D of all three TLS base documemts apply 1169 accordingly. 1171 Security discussions specific to ECC can be found in 1172 [IEEE.P1363.1998] and [ANSI.X9-62.2005]. One important issue that 1173 implementers and users must consider is elliptic curve selection. 1174 Guidance on selecting an appropriate elliptic curve size is given in 1175 Table 1. 1177 Beyond elliptic curve size, the main issue is elliptic curve 1178 structure. As a general principle, it is more conservative to use 1179 elliptic curves with as little algebraic structure as possible. 1180 Thus, random curves are more conservative than special curves such as 1181 Koblitz curves, and curves over F_p with p random are more 1182 conservative than curves over F_p with p of a special form (and 1183 curves over F_p with p random might be considered more conservative 1184 than curves over F_2^m as there is no choice between multiple fields 1185 of similar size for characteristic 2). Note, however, that algebraic 1186 structure can also lead to implementation efficiencies, and 1187 implementers and users may, therefore, need to balance conservatism 1188 against a need for efficiency. Concrete attacks are known against 1189 only very few special classes of curves, such as supersingular 1190 curves, and these classes are excluded from the ECC standards that 1191 this document references [IEEE.P1363.1998], [ANSI.X9-62.2005]. 1193 Another issue is the potential for catastrophic failures when a 1194 single elliptic curve is widely used. In this case, an attack on the 1195 elliptic curve might result in the compromise of a large number of 1196 keys. Again, this concern may need to be balanced against efficiency 1197 and interoperability improvements associated with widely-used curves. 1198 Substantial additional information on elliptic curve choice can be 1199 found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]. 1201 All of the key exchange algorithms defined in this document provide 1202 forward secrecy. Some of the deprecated key exchange algorithms do 1203 not. 1205 8. IANA Considerations 1207 [RFC4492], the predecessor of this document has already defined the 1208 IANA registries for the following: 1210 o Supported Groups Section 5.1 1211 o ECPointFormat Section 5.1 1212 o ECCurveType Section 5.4 1214 For each name space, this document defines the initial value 1215 assignments and defines a range of 256 values (NamedCurve) or eight 1216 values (ECPointFormat and ECCurveType) reserved for Private Use. The 1217 policy for any additional assignments is "Specification Required". 1218 The previous version of this document required IETF review. 1220 NOTE: IANA, please update the registries to reflect the new policy. 1222 NOTE: RFC editor please delete these two notes prior to publication. 1224 IANA, please update these two registries to refer to this document. 1226 IANA is requested to assign two values from the NamedCurve registry 1227 with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this 1228 document as reference. IANA has already assigned the value 29 to 1229 ecdh_x25519, and the value 30 to ecdh_x448(TBD2). 1231 IANA is requested to assign one value from SignatureAlgorithm 1232 Registry with name eddsa(TBD5) with this document as reference. 1234 9. Acknowledgements 1236 Most of the text is this document is taken from [RFC4492], the 1237 predecessor of this document. The authors of that document were: 1239 o Simon Blake-Wilson 1240 o Nelson Bolyard 1241 o Vipul Gupta 1242 o Chris Hawk 1243 o Bodo Moeller 1245 In the predecessor document, the authors acknowledged the 1246 contributions of Bill Anderson and Tim Dierks. 1248 10. Version History for This Draft 1250 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION 1252 Changes from draft-ietf-tls-rfc4492bis-03 to draft-nir-tls- 1253 rfc4492bis-05: 1255 o Add support for CFRG curves and signatures work. 1257 Changes from draft-ietf-tls-rfc4492bis-01 to draft-nir-tls- 1258 rfc4492bis-03: 1260 o Removed unused curves. 1261 o Removed unused point formats (all but uncompressed) 1263 Changes from draft-nir-tls-rfc4492bis-00 and draft-ietf-tls- 1264 rfc4492bis-00 to draft-nir-tls-rfc4492bis-01: 1266 o Merged errata 1267 o Removed ECDH_RSA and ECDH_ECDSA 1269 Changes from RFC 4492 to draft-nir-tls-rfc4492bis-00: 1271 o Added TLS 1.2 to references. 1272 o Moved RFC 4492 authors to acknowledgements. 1273 o Removed list of required reading for ECC. 1275 11. References 1277 11.1. Normative References 1279 [ANSI.X9-62.2005] 1280 American National Standards Institute, "Public Key 1281 Cryptography for the Financial Services Industry, The 1282 Elliptic Curve Digital Signature Algorithm (ECDSA)", 1283 ANSI X9.62, 2005. 1285 [CCITT.X680] 1286 International Telephone and Telegraph Consultative 1287 Committee, "Abstract Syntax Notation One (ASN.1): 1288 Specification of basic notation", CCITT Recommendation 1289 X.680, July 2002. 1291 [CCITT.X690] 1292 International Telephone and Telegraph Consultative 1293 Committee, "ASN.1 encoding rules: Specification of basic 1294 encoding Rules (BER), Canonical encoding rules (CER) and 1295 Distinguished encoding rules (DER)", CCITT Recommendation 1296 X.690, July 2002. 1298 [CFRG-EdDSA] 1299 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 1300 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-00 1301 (work in progress), October 2015. 1303 [FIPS.186-4] 1304 National Institute of Standards and Technology, "Digital 1305 Signature Standard", FIPS PUB 186-4, 2013, 1306 . 1309 [PKCS1] RSA Laboratories, "RSA Encryption Standard, Version 1.5", 1310 PKCS 1, November 1993. 1312 [PKIX-EdDSA] 1313 Josefsson, S. and N. Mavrogiannopoulos, "Using EdDSA in 1314 the Internet X.509 Public Key Infrastructure", draft- 1315 josefsson-pkix-eddsa-03 (work in progress), September 1316 2015. 1318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1319 Requirement Levels", BCP 14, RFC 2119, March 1997. 1321 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1322 RFC 2246, January 1999. 1324 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1325 Identifiers for the Internet X.509 Public Key 1326 Infrastructure Certificate and Certificate Revocation List 1327 (CRL) Profile", RFC 3279, April 2002. 1329 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1330 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1332 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1333 and T. Wright, "Transport Layer Security (TLS) 1334 Extensions", RFC 4366, April 2006. 1336 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1337 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1339 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1340 for Security", RFC 7748, January 2016. 1342 [SECG-SEC2] 1343 CECG, "Recommended Elliptic Curve Domain Parameters", 1344 SEC 2, 2000. 1346 11.2. Informative References 1348 [FIPS.180-2] 1349 National Institute of Standards and Technology, "Secure 1350 Hash Standard", FIPS PUB 180-2, August 2002, 1351 . 1354 [I-D.ietf-tls-tls13] 1355 Dierks, T. and E. Rescorla, "The Transport Layer Security 1356 (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-02 (work 1357 in progress), July 2014. 1359 [IEEE.P1363.1998] 1360 Institute of Electrical and Electronics Engineers, 1361 "Standard Specifications for Public Key Cryptography", 1362 IEEE Draft P1363, 1998. 1364 [Lenstra_Verheul] 1365 Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1366 Sizes", Journal of Cryptology 14 (2001) 255-293, 2001. 1368 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1369 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1370 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1372 Appendix A. Equivalent Curves (Informative) 1374 All of the NIST curves [FIPS.186-4] and several of the ANSI curves 1375 [ANSI.X9-62.2005] are equivalent to curves listed in Section 5.1.1. 1376 In the following table, multiple names in one row represent aliases 1377 for the same curve. 1379 Curve names chosen by different standards organizations 1381 +-----------+------------+------------+ 1382 | SECG | ANSI X9.62 | NIST | 1383 +-----------+------------+------------+ 1384 | sect163k1 | | NIST K-163 | 1385 | sect163r1 | | | 1386 | sect163r2 | | NIST B-163 | 1387 | sect193r1 | | | 1388 | sect193r2 | | | 1389 | sect233k1 | | NIST K-233 | 1390 | sect233r1 | | NIST B-233 | 1391 | sect239k1 | | | 1392 | sect283k1 | | NIST K-283 | 1393 | sect283r1 | | NIST B-283 | 1394 | sect409k1 | | NIST K-409 | 1395 | sect409r1 | | NIST B-409 | 1396 | sect571k1 | | NIST K-571 | 1397 | sect571r1 | | NIST B-571 | 1398 | secp160k1 | | | 1399 | secp160r1 | | | 1400 | secp160r2 | | | 1401 | secp192k1 | | | 1402 | secp192r1 | prime192v1 | NIST P-192 | 1403 | secp224k1 | | | 1404 | secp224r1 | | NIST P-224 | 1405 | secp256k1 | | | 1406 | secp256r1 | prime256v1 | NIST P-256 | 1407 | secp384r1 | | NIST P-384 | 1408 | secp521r1 | | NIST P-521 | 1409 +-----------+------------+------------+ 1411 Table 6: Equivalent curves defined by SECG, ANSI, and NIST 1413 Appendix B. Differences from RFC 4492 1415 o Added TLS 1.2 1416 o Merged Errata 1417 o Removed the ECDH key exchange algorithms: ECDH_RSA and ECDH_ECDSA 1418 o Deprecated a bunch of ciphersuites: 1420 TLS_ECDH_ECDSA_WITH_NULL_SHA 1421 TLS_ECDH_ECDSA_WITH_RC4_128_SHA 1422 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA 1423 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 1424 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 1425 TLS_ECDH_RSA_WITH_NULL_SHA 1426 TLS_ECDH_RSA_WITH_RC4_128_SHA 1427 TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA 1428 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 1429 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 1430 All the other RC4 ciphersuites 1432 Removed unused curves and all but the uncompressed point format. 1434 Added X25519 and X448. 1436 Deprecated explicit curves. 1438 Removed restriction on signature algorithm in certificate. 1440 Authors' Addresses 1442 Yoav Nir 1443 Check Point Software Technologies Ltd. 1444 5 Hasolelim st. 1445 Tel Aviv 6789735 1446 Israel 1448 Email: ynir.ietf@gmail.com 1450 Simon Josefsson 1451 SJD AB 1453 Email: simon@josefsson.org 1455 Manuel Pegourie-Gonnard 1456 Independent / PolarSSL 1458 Email: mpg@elzevir.fr