idnits 2.17.1 draft-ietf-tls-rfc4492bis-16.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 683 has weird spacing: '...rveType cur...' == Line 699 has weird spacing: '...ameters cur...' == Line 719 has weird spacing: '...HParams par...' == Line 814 has weird spacing: '...ionForm form;...' -- The document date (March 23, 2017) is 2563 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 186, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' -- Possible downref: Non-RFC (?) normative reference: 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 ** Downref: Normative reference to an Informational RFC: RFC 8032 -- Possible downref: Non-RFC (?) normative reference: ref. 'SECG-SEC2' == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 6 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 24, 2017 M. Pegourie-Gonnard 7 Independent / PolarSSL 8 March 23, 2017 10 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer 11 Security (TLS) Versions 1.2 and Earlier 12 draft-ietf-tls-rfc4492bis-16 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 authentication mechanisms. 23 This document obsoletes and replaces RFC 4492. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 24, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 61 2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 3 62 2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.4. Algorithms in Certificate Chains . . . . . . . . . . . . 6 66 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 6 67 3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7 68 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 7 69 5. Data Structures and Computations . . . . . . . . . . . . . . 8 70 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8 71 5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 10 72 5.1.2. Supported Point Formats Extension . . . . . . . . . . 11 73 5.1.3. The signature_algorithms Extension and EdDSA . . . . 12 74 5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 12 75 5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 13 76 5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 14 77 5.4.1. Uncompressed Point Format for NIST curves . . . . . . 18 78 5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 18 79 5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 19 80 5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 20 81 5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 21 82 5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 23 83 5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 23 84 5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 24 85 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 24 86 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 90 11. Version History for This Draft . . . . . . . . . . . . . . . 28 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 93 12.2. Informative References . . . . . . . . . . . . . . . . . 30 94 Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 30 95 Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 31 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 98 1. Introduction 100 This document describes additions to TLS to support ECC, applicable 101 to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246]. The 102 use of ECC in TLS 1.3 is defined in [I-D.ietf-tls-tls13], and is 103 explicitly out of scope for this document. In particular, this 104 document defines: 106 o the use of the ECDHE key agreement scheme with ephemeral keys to 107 establish the TLS premaster secret, and 108 o the use of ECDSA and EdDSA signatures for authentication of TLS 109 peers. 111 The remainder of this document is organized as follows. Section 2 112 provides an overview of ECC-based key exchange algorithms for TLS. 113 Section 3 describes the use of ECC certificates for client 114 authentication. TLS extensions that allow a client to negotiate the 115 use of specific curves and point formats are presented in Section 4. 116 Section 5 specifies various data structures needed for an ECC-based 117 handshake, their encoding in TLS messages, and the processing of 118 those messages. Section 6 defines ECC-based cipher suites and 119 identifies a small subset of these as recommended for all 120 implementations of this specification. Section 8 discusses security 121 considerations. Section 9 describes IANA considerations for the name 122 spaces created by this document's predecessor. Section 10 gives 123 acknowledgements. Appendix B provides differences from [RFC4492], 124 the document that this one replaces. 126 Implementation of this specification requires familiarity with TLS, 127 TLS extensions [RFC4366], and ECC. 129 1.1. Conventions Used in This Document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 2. Key Exchange Algorithm 137 This document defines three new ECC-based key exchange algorithms for 138 TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS 139 premaster secret, and they differ only in the mechanism (if any) used 140 to authenticate them. The derivation of the TLS master secret from 141 the premaster secret and the subsequent generation of bulk 142 encryption/MAC keys and initialization vectors is independent of the 143 key exchange algorithm and not impacted by the introduction of ECC. 145 Table 1 summarizes the new key exchange algorithms. All of these key 146 exchange algorithms provide forward secrecy if and only if fresh 147 ephemeral keys are generated and used, and also destroyed after use. 149 +-------------+------------------------------------------------+ 150 | Algorithm | Description | 151 +-------------+------------------------------------------------+ 152 | ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. | 153 | ECDHE_RSA | Ephemeral ECDH with RSA signatures. | 154 | ECDH_anon | Anonymous ephemeral ECDH, no signatures. | 155 +-------------+------------------------------------------------+ 157 Table 1: ECC Key Exchange Algorithms 159 These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, 160 respectively. 162 With ECDHE_RSA, a server can reuse its existing RSA certificate and 163 easily comply with a constrained client's elliptic curve preferences 164 (see Section 4). However, the computational cost incurred by a 165 server is higher for ECDHE_RSA than for the traditional RSA key 166 exchange, which does not provide forward secrecy. 168 The anonymous key exchange algorithm does not provide authentication 169 of the server or the client. Like other anonymous TLS key exchanges, 170 it is subject to man-in-the-middle attacks. Applications using TLS 171 with this algorithm SHOULD provide authentication by other means. 173 Client Server 174 ------ ------ 175 ClientHello --------> 176 ServerHello 177 Certificate* 178 ServerKeyExchange* 179 CertificateRequest*+ 180 <-------- ServerHelloDone 181 Certificate*+ 182 ClientKeyExchange 183 CertificateVerify*+ 184 [ChangeCipherSpec] 185 Finished --------> 186 [ChangeCipherSpec] 187 <-------- Finished 188 Application Data <-------> Application Data 189 * message is not sent under some conditions 190 + message is not sent unless client authentication 191 is desired 193 Figure 1: Message flow in a full TLS 1.2 handshake 195 Figure 1 shows all messages involved in the TLS key establishment 196 protocol (aka full handshake). The addition of ECC has direct impact 197 only on the ClientHello, the ServerHello, the server's Certificate 198 message, the ServerKeyExchange, the ClientKeyExchange, the 199 CertificateRequest, the client's Certificate message, and the 200 CertificateVerify. Next, we describe the ECC key exchange algorithm 201 in greater detail in terms of the content and processing of these 202 messages. For ease of exposition, we defer discussion of client 203 authentication and associated messages (identified with a + in 204 Figure 1) until Section 3 and of the optional ECC-specific extensions 205 (which impact the Hello messages) until Section 4. 207 2.1. ECDHE_ECDSA 209 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- or 210 EdDSA-capable public key. 212 The server sends its ephemeral ECDH public key and a specification of 213 the corresponding curve in the ServerKeyExchange message. These 214 parameters MUST be signed with ECDSA or EdDSA using the private key 215 corresponding to the public key in the server's Certificate. 217 The client generates an ECDH key pair on the same curve as the 218 server's ephemeral ECDH key and sends its public key in the 219 ClientKeyExchange message. 221 Both client and server perform an ECDH operation Section 5.10 and use 222 the resultant shared secret as the premaster secret. 224 2.2. ECDHE_RSA 226 This key exchange algorithm is the same as ECDHE_ECDSA except that 227 the server's certificate MUST contain an RSA public key authorized 228 for signing, and that the signature in the ServerKeyExchange message 229 must be computed with the corresponding RSA private key. 231 2.3. ECDH_anon 233 NOTE: Despite the name beginning with "ECDH_" (no E), the key used in 234 ECDH_anon is ephemeral just like the key in ECDHE_RSA and 235 ECDHE_ECDSA. The naming follows the example of DH_anon, where the 236 key is also ephemeral but the name does not reflect it. 238 In ECDH_anon, the server's Certificate, the CertificateRequest, the 239 client's Certificate, and the CertificateVerify messages MUST NOT be 240 sent. 242 The server MUST send an ephemeral ECDH public key and a specification 243 of the corresponding curve in the ServerKeyExchange message. These 244 parameters MUST NOT be signed. 246 The client generates an ECDH key pair on the same curve as the 247 server's ephemeral ECDH key and sends its public key in the 248 ClientKeyExchange message. 250 Both client and server perform an ECDH operation and use the 251 resultant shared secret as the premaster secret. All ECDH 252 calculations are performed as specified in Section 5.10. 254 2.4. Algorithms in Certificate Chains 256 This specification does not impose restrictions on signature schemes 257 used anywhere in the certificate chain. The previous version of this 258 document required the signatures to match, but this restriction, 259 originating in previous TLS versions is lifted here as it had been in 260 RFC 5246. 262 3. Client Authentication 264 This document defines a client authentication mechanism, named after 265 the type of client certificate involved: ECDSA_sign. The ECDSA_sign 266 mechanism is usable with any of the non-anonymous ECC key exchange 267 algorithms described in Section 2 as well as other non-anonymous 268 (non-ECC) key exchange algorithms defined in TLS. 270 Note that client certificates with EdDSA public keys also use this 271 mechanism. 273 The server can request ECC-based client authentication by including 274 this certificate type in its CertificateRequest message. The client 275 must check if it possesses a certificate appropriate for the method 276 suggested by the server and is willing to use it for authentication. 278 If these conditions are not met, the client SHOULD send a client 279 Certificate message containing no certificates. In this case, the 280 ClientKeyExchange MUST be sent as described in Section 2, and the 281 CertificateVerify MUST NOT be sent. If the server requires client 282 authentication, it may respond with a fatal handshake failure alert. 284 If the client has an appropriate certificate and is willing to use it 285 for authentication, it must send that certificate in the client's 286 Certificate message (as per Section 5.6) and prove possession of the 287 private key corresponding to the certified key. The process of 288 determining an appropriate certificate and proving possession is 289 different for each authentication mechanism and described below. 291 NOTE: It is permissible for a server to request (and the client to 292 send) a client certificate of a different type than the server 293 certificate. 295 3.1. ECDSA_sign 297 To use this authentication mechanism, the client MUST possess a 298 certificate containing an ECDSA- or EdDSA-capable public key. 300 The client proves possession of the private key corresponding to the 301 certified key by including a signature in the CertificateVerify 302 message as described in Section 5.8. 304 4. TLS Extensions for ECC 306 Two TLS extensions are defined in this specification: (i) the 307 Supported Elliptic Curves Extension, and (ii) the Supported Point 308 Formats Extension. These allow negotiating the use of specific 309 curves and point formats (e.g., compressed vs. uncompressed, 310 respectively) during a handshake starting a new session. These 311 extensions are especially relevant for constrained clients that may 312 only support a limited number of curves or point formats. They 313 follow the general approach outlined in [RFC4366]; message details 314 are specified in Section 5. The client enumerates the curves it 315 supports and the point formats it can parse by including the 316 appropriate extensions in its ClientHello message. The server 317 similarly enumerates the point formats it can parse by including an 318 extension in its ServerHello message. 320 A TLS client that proposes ECC cipher suites in its ClientHello 321 message SHOULD include these extensions. Servers implementing ECC 322 cipher suites MUST support these extensions, and when a client uses 323 these extensions, servers MUST NOT negotiate the use of an ECC cipher 324 suite unless they can complete the handshake while respecting the 325 choice of curves specified by the client. This eliminates the 326 possibility that a negotiated ECC handshake will be subsequently 327 aborted due to a client's inability to deal with the server's EC key. 329 The client MUST NOT include these extensions in the ClientHello 330 message if it does not propose any ECC cipher suites. A client that 331 proposes ECC cipher suites may choose not to include these 332 extensions. In this case, the server is free to choose any one of 333 the elliptic curves or point formats listed in Section 5. That 334 section also describes the structure and processing of these 335 extensions in greater detail. 337 In the case of session resumption, the server simply ignores the 338 Supported Elliptic Curves Extension and the Supported Point Formats 339 Extension appearing in the current ClientHello message. These 340 extensions only play a role during handshakes negotiating a new 341 session. 343 5. Data Structures and Computations 345 This section specifies the data structures and computations used by 346 ECC-based key mechanisms specified in the previous three sections. 347 The presentation language used here is the same as that used in TLS. 348 Since this specification extends TLS, these descriptions should be 349 merged with those in the TLS specification and any others that extend 350 TLS. This means that enum types may not specify all possible values, 351 and structures with multiple formats chosen with a select() clause 352 may not indicate all possible cases. 354 5.1. Client Hello Extensions 356 This section specifies two TLS extensions that can be included with 357 the ClientHello message as described in [RFC4366], the Supported 358 Elliptic Curves Extension and the Supported Point Formats Extension. 360 When these extensions are sent: 362 The extensions SHOULD be sent along with any ClientHello message that 363 proposes ECC cipher suites. 365 Meaning of these extensions: 367 These extensions allow a client to enumerate the elliptic curves it 368 supports and/or the point formats it can parse. 370 Structure of these extensions: 372 The general structure of TLS extensions is described in [RFC4366], 373 and this specification adds two types to ExtensionType. 375 enum { 376 elliptic_curves(10), 377 ec_point_formats(11) 378 } ExtensionType; 380 o elliptic_curves (Supported Elliptic Curves Extension): Indicates 381 the set of elliptic curves supported by the client. For this 382 extension, the opaque extension_data field contains 383 NamedCurveList. See Section 5.1.1 for details. 384 o ec_point_formats (Supported Point Formats Extension): Indicates 385 the set of point formats that the client can parse. For this 386 extension, the opaque extension_data field contains 387 ECPointFormatList. See Section 5.1.2 for details. 389 Actions of the sender: 391 A client that proposes ECC cipher suites in its ClientHello message 392 appends these extensions (along with any others), enumerating the 393 curves it supports and the point formats it can parse. Clients 394 SHOULD send both the Supported Elliptic Curves Extension and the 395 Supported Point Formats Extension. If the Supported Point Formats 396 Extension is indeed sent, it MUST contain the value 0 (uncompressed) 397 as one of the items in the list of point formats. 399 Actions of the receiver: 401 A server that receives a ClientHello containing one or both of these 402 extensions MUST use the client's enumerated capabilities to guide its 403 selection of an appropriate cipher suite. One of the proposed ECC 404 cipher suites must be negotiated only if the server can successfully 405 complete the handshake while using the curves and point formats 406 supported by the client (cf. Section 5.3 and Section 5.4). 408 NOTE: A server participating in an ECDHE_ECDSA key exchange may use 409 different curves for the ECDSA or EdDSA key in its certificate, and 410 for the ephemeral ECDH key in the ServerKeyExchange message. The 411 server MUST consider the extensions in both cases. 413 If a server does not understand the Supported Elliptic Curves 414 Extension, does not understand the Supported Point Formats Extension, 415 or is unable to complete the ECC handshake while restricting itself 416 to the enumerated curves and point formats, it MUST NOT negotiate the 417 use of an ECC cipher suite. Depending on what other cipher suites 418 are proposed by the client and supported by the server, this may 419 result in a fatal handshake failure alert due to the lack of common 420 cipher suites. 422 5.1.1. Supported Elliptic Curves Extension 424 RFC 4492 defined 25 different curves in the NamedCurve registry (now 425 renamed the "Supported Groups" registry, although the enumeration 426 below is still named NamedCurve) for use in TLS. Only three have 427 seen much use. This specification is deprecating the rest (with 428 numbers 1-22). This specification also deprecates the explicit 429 curves with identifiers 0xFF01 and 0xFF02. It also adds the new 430 curves defined in [RFC7748]. The end result is as follows: 432 enum { 433 deprecated(1..22), 434 secp256r1 (23), secp384r1 (24), secp521r1 (25), 435 x25519(29), x448(30), 436 reserved (0xFE00..0xFEFF), 437 deprecated(0xFF01..0xFF02), 438 (0xFFFF) 439 } NamedCurve; 441 Note that other specifications have since added other values to this 442 enumeration. Some of those values are not curves at all, but finite 443 field groups. See [RFC7919]. 445 secp256r1, etc: Indicates support of the corresponding named curve or 446 groups. The named curves secp256r1, secp384r1, and secp521r1 are 447 specified in SEC 2 [SECG-SEC2]. These curves are also recommended in 448 ANSI X9.62 [ANSI.X9-62.2005] and FIPS 186-4 [FIPS.186-4]. The rest 449 of this document refers to these three curves as the "NIST curves" 450 because they were originally standardized by the National Institute 451 of Standards and Technology. The curves x25519 and x448 are defined 452 in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for private 453 use. 455 The predecessor of this document also supported explicitly defined 456 prime and char2 curves, but these are deprecated by this 457 specification. 459 The NamedCurve name space is maintained by IANA. See Section 9 for 460 information on how new value assignments are added. 462 struct { 463 NamedCurve named_curve_list<2..2^16-1> 464 } NamedCurveList; 466 Items in named_curve_list are ordered according to the client's 467 preferences (favorite choice first). 469 As an example, a client that only supports secp256r1 (aka NIST P-256; 470 value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) 471 and prefers to use secp256r1 would include a TLS extension consisting 472 of the following octets. Note that the first two octets indicate the 473 extension type (Supported Elliptic Curves Extension): 475 00 0A 00 06 00 04 00 17 00 18 477 5.1.2. Supported Point Formats Extension 479 enum { 480 uncompressed (0), 481 deprecated (1..2), 482 reserved (248..255) 483 } ECPointFormat; 484 struct { 485 ECPointFormat ec_point_format_list<1..2^8-1> 486 } ECPointFormatList; 488 Three point formats were included in the definition of ECPointFormat 489 above. This specification deprecates all but the uncompressed point 490 format. Implementations of this document MUST support the 491 uncompressed format for all of their supported curves, and MUST NOT 492 support other formats for curves defined in this specification. For 493 backwards compatibility purposes, the point format list extension MAY 494 still be included, and contain exactly one value: the uncompressed 495 point format (0). RFC 4492 specified that if this extension is 496 missing, it means that only the uncompressed point format is 497 supported, so interoperability with implementations that support the 498 uncompressed format should work with or without the extension. 500 If the client sends the extension and the extension does not contain 501 the uncompressed point format, and the client has used the Supported 502 Groups extension to indicate support for any of the curves defined in 503 this specification then the server MUST abort the handshake and 504 return an illegal_parameter alert. 506 The ECPointFormat name space is maintained by IANA. See Section 9 507 for information on how new value assignments are added. 509 A client compliant with this specification that supports no other 510 curves MUST send the following octets; note that the first two octets 511 indicate the extension type (Supported Point Formats Extension): 513 00 0B 00 02 01 00 515 5.1.3. The signature_algorithms Extension and EdDSA 517 The signature_algorithms extension, defined in section 7.4.1.4.1 of 518 [RFC5246], advertises the combinations of signature algorithm and 519 hash function that the client supports. The pure (non pre-hashed) 520 forms of EdDSA do not hash the data before signing it. For this 521 reason it does not make sense to combine them with a signature 522 algorithm in the extension. 524 For bits-on-the-wire compatibility with TLS 1.3, we define a new 525 dummy value in the HashAlgorithm registry which we will call 526 "Intrinsic" (value TBD5) meaning that hashing is intrinsic to the 527 signature algorithm. 529 To represent ed25519 and ed448 in the signature_algorithms extension, 530 the value shall be (TBD5,TBD3) and (TBD5,TBD4) respectively. 532 5.2. Server Hello Extension 534 This section specifies a TLS extension that can be included with the 535 ServerHello message as described in [RFC4366], the Supported Point 536 Formats Extension. 538 When this extension is sent: 540 The Supported Point Formats Extension is included in a ServerHello 541 message in response to a ClientHello message containing the Supported 542 Point Formats Extension when negotiating an ECC cipher suite. 544 Meaning of this extension: 546 This extension allows a server to enumerate the point formats it can 547 parse (for the curve that will appear in its ServerKeyExchange 548 message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key 549 exchange algorithm. 551 Structure of this extension: 553 The server's Supported Point Formats Extension has the same structure 554 as the client's Supported Point Formats Extension (see 555 Section 5.1.2). Items in ec_point_format_list here are ordered 556 according to the server's preference (favorite choice first). Note 557 that the server MAY include items that were not found in the client's 558 list. However, without extensions this specification allows exactly 559 one point format, so there is not really any opportunity for 560 mismatches. 562 Actions of the sender: 564 A server that selects an ECC cipher suite in response to a 565 ClientHello message including a Supported Point Formats Extension 566 appends this extension (along with others) to its ServerHello 567 message, enumerating the point formats it can parse. The Supported 568 Point Formats Extension, when used, MUST contain the value 0 569 (uncompressed) as one of the items in the list of point formats. 571 Actions of the receiver: 573 A client that receives a ServerHello message containing a Supported 574 Point Formats Extension MUST respect the server's choice of point 575 formats during the handshake (cf. Section 5.6 and Section 5.7). If 576 no Supported Point Formats Extension is received with the 577 ServerHello, this is equivalent to an extension allowing only the 578 uncompressed point format. 580 5.3. Server Certificate 582 When this message is sent: 584 This message is sent in all non-anonymous ECC-based key exchange 585 algorithms. 587 Meaning of this message: 589 This message is used to authentically convey the server's static 590 public key to the client. The following table shows the server 591 certificate type appropriate for each key exchange algorithm. ECC 592 public keys MUST be encoded in certificates as described in 593 Section 5.9. 595 NOTE: The server's Certificate message is capable of carrying a chain 596 of certificates. The restrictions mentioned in Table 3 apply only to 597 the server's certificate (first in the chain). 599 +-------------+-----------------------------------------------------+ 600 | Algorithm | Server Certificate Type | 601 +-------------+-----------------------------------------------------+ 602 | ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable | 603 | | public key. | 604 | ECDHE_RSA | Certificate MUST contain an RSA public key. | 605 +-------------+-----------------------------------------------------+ 607 Table 2: Server Certificate Types 609 Structure of this message: 611 Identical to the TLS Certificate format. 613 Actions of the sender: 615 The server constructs an appropriate certificate chain and conveys it 616 to the client in the Certificate message. If the client has used a 617 Supported Elliptic Curves Extension, the public key in the server's 618 certificate MUST respect the client's choice of elliptic curves. A 619 server that cannot satisfy this requirement MUST NOT choose an ECC 620 cipher suite in its ServerHello message.) 622 Actions of the receiver: 624 The client validates the certificate chain, extracts the server's 625 public key, and checks that the key type is appropriate for the 626 negotiated key exchange algorithm. (A possible reason for a fatal 627 handshake failure is that the client's capabilities for handling 628 elliptic curves and point formats are exceeded; cf. Section 5.1.) 630 5.4. Server Key Exchange 632 When this message is sent: 634 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and 635 ECDH_anon key exchange algorithms. 637 Meaning of this message: 639 This message is used to convey the server's ephemeral ECDH public key 640 (and the corresponding elliptic curve domain parameters) to the 641 client. 643 The ECCCurveType enum used to have values for explicit prime and for 644 explicit char2 curves. Those values are now deprecated, so only one 645 value remains: 647 Structure of this message: 649 enum { 650 deprecated (1..2), 651 named_curve (3), 652 reserved(248..255) 653 } ECCurveType; 655 The value named_curve indicates that a named curve is used. This 656 option is now the only remaining format. 658 Values 248 through 255 are reserved for private use. 660 The ECCurveType name space is maintained by IANA. See Section 9 for 661 information on how new value assignments are added. 663 RFC 4492 had a specification for an ECCurve structure and an 664 ECBasisType structure. Both of these are omitted now because they 665 were only used with the now deprecated explicit curves. 667 struct { 668 opaque point <1..2^8-1>; 669 } ECPoint; 671 point: This is the byte string representation of an elliptic curve 672 point following the conversion routine in Section 4.3.6 of 673 [ANSI.X9-62.2005]. This byte string may represent an elliptic curve 674 point in uncompressed, compressed, or hybrid format, but this 675 specification deprecates all but the uncompressed format. For the 676 NIST curves, the format is repeated in Section 5.4.1 for convenience. 677 For the X25519 and X448 curves, the only valid representation is the 678 one specified in [RFC7748] - a 32- or 56-octet representation of the 679 u value of the point. This structure MUST NOT be used with Ed25519 680 and Ed448 public keys. 682 struct { 683 ECCurveType curve_type; 684 select (curve_type) { 685 case named_curve: 686 NamedCurve namedcurve; 687 }; 688 } ECParameters; 690 curve_type: This identifies the type of the elliptic curve domain 691 parameters. 693 namedCurve: Specifies a recommended set of elliptic curve domain 694 parameters. All those values of NamedCurve are allowed that refer to 695 a curve capable of Diffie-Hellman. With the deprecation of the 696 explicit curves, this now includes all of the NamedCurve values. 698 struct { 699 ECParameters curve_params; 700 ECPoint public; 701 } ServerECDHParams; 703 curve_params: Specifies the elliptic curve domain parameters 704 associated with the ECDH public key. 706 public: The ephemeral ECDH public key. 708 The ServerKeyExchange message is extended as follows. 710 enum { 711 ec_diffie_hellman 712 } KeyExchangeAlgorithm; 714 o ec_diffie_hellman: Indicates the ServerKeyExchange message 715 contains an ECDH public key. 717 select (KeyExchangeAlgorithm) { 718 case ec_diffie_hellman: 719 ServerECDHParams params; 720 Signature signed_params; 721 } ServerKeyExchange; 723 o params: Specifies the ECDH public key and associated domain 724 parameters. 725 o signed_params: A hash of the params, with the signature 726 appropriate to that hash applied. The private key corresponding 727 to the certified public key in the server's Certificate message is 728 used for signing. 730 enum { 731 ecdsa(3), 732 ed25519(TBD3) 733 ed448(TBD4) 734 } SignatureAlgorithm; 735 select (SignatureAlgorithm) { 736 case ecdsa: 737 digitally-signed struct { 738 opaque sha_hash[sha_size]; 739 }; 740 case ed25519,ed448: 741 digitally-signed struct { 742 opaque rawdata[rawdata_size]; 743 }; 744 } Signature; 745 ServerKeyExchange.signed_params.sha_hash 746 SHA(ClientHello.random + ServerHello.random + 747 ServerKeyExchange.params); 748 ServerKeyExchange.signed_params.rawdata 749 ClientHello.random + ServerHello.random + 750 ServerKeyExchange.params; 752 NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange 753 algorithm and "anonymous" for ECDH_anon. These cases are defined in 754 TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA. 755 ECDSA signatures are generated and verified as described in 756 Section 5.10, and SHA in the above template for sha_hash accordingly 757 may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an 758 ECDSA signature consists of a pair of integers, r and s. The 759 digitally-signed element is encoded as an opaque vector <0..2^16-1>, 760 the contents of which are the DER encoding corresponding to the 761 following ASN.1 notation. 763 Ecdsa-Sig-Value ::= SEQUENCE { 764 r INTEGER, 765 s INTEGER 766 } 768 EdDSA signatures in both the protocol and in certificates that 769 conform to [PKIX-EdDSA] are generated and verified according to 770 [RFC8032]. 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.4.1. Uncompressed Point Format for NIST curves 793 The following represents the wire format for representing ECPoint in 794 ServerKeyExchange records. The first octet of the representation 795 indicates the form, which may be compressed, uncompressed, or hybrid. 796 This specification supports only the uncompressed format for these 797 curves. This is followed by the binary representation of the X value 798 in "big-endian" or "network" format, followed by the binary 799 representation of the Y value in "big-endian" or "network" format. 800 There are no internal length markers, so each number representation 801 occupies as many octets as implied by the curve parameters. For 802 P-256 this means that each of X and Y use 32 octets, padded on the 803 left by zeros if necessary. For P-384 they take 48 octets each, and 804 for P-521 they take 66 octets each. 806 Here's a more formal representation: 808 enum { 809 uncompressed(4), 810 (255) 811 } PointConversionForm; 813 struct { 814 PointConversionForm form; 815 opaque X[coordinate_length]; 816 opaque Y[coordinate_length]; 817 } UncompressedPointRepresentation; 819 5.5. Certificate Request 821 When this message is sent: 823 This message is sent when requesting client authentication. 825 Meaning of this message: 827 The server uses this message to suggest acceptable client 828 authentication methods. 830 Structure of this message: 832 The TLS CertificateRequest message is extended as follows. 834 enum { 835 ecdsa_sign(64), 836 deprecated1(65), /* was rsa_fixed_ecdh */ 837 deprecated2(66), /* was ecdsa_fixed_ecdh */ 838 (255) 839 } ClientCertificateType; 841 o ecdsa_sign: Indicates that the server would like to use the 842 corresponding client authentication method specified in Section 3. 844 Note that RFC 4492 also defined RSA and ECDSA certificates that 845 included a fixed ECDH public key. These mechanisms saw very little 846 implementation so this specification is deprecating them. 848 Actions of the sender: 850 The server decides which client authentication methods it would like 851 to use, and conveys this information to the client using the format 852 defined above. 854 Actions of the receiver: 856 The client determines whether it has a suitable certificate for use 857 with any of the requested methods and whether to proceed with client 858 authentication. 860 5.6. Client Certificate 862 When this message is sent: 864 This message is sent in response to a CertificateRequest when a 865 client has a suitable certificate and has decided to proceed with 866 client authentication. (Note that if the server has used a Supported 867 Point Formats Extension, a certificate can only be considered 868 suitable for use with the ECDSA_sign authentication method if the 869 public key point specified in it is uncompressed, as that is the only 870 point format still supported. 872 Meaning of this message: 874 This message is used to authentically convey the client's static 875 public key to the server. The following table summarizes what client 876 certificate types are appropriate for the ECC-based client 877 authentication mechanisms described in Section 3. ECC public keys 878 must be encoded in certificates as described in Section 5.9. 880 NOTE: The client's Certificate message is capable of carrying a chain 881 of certificates. The restrictions mentioned in Table 4 apply only to 882 the client's certificate (first in the chain). 884 The certificate MUST contain an ECDSA- or EdDSA-capable public key. 886 Structure of this message: 888 Identical to the TLS client Certificate format. 890 Actions of the sender: 892 The client constructs an appropriate certificate chain, and conveys 893 it to the server in the Certificate message. 895 Actions of the receiver: 897 The TLS server validates the certificate chain, extracts the client's 898 public key, and checks that the key type is appropriate for the 899 client authentication method. 901 5.7. Client Key Exchange 903 When this message is sent: 905 This message is sent in all key exchange algorithms. It contains the 906 client's ephemeral ECDH public key. 908 Meaning of the message: 910 This message is used to convey ephemeral data relating to the key 911 exchange belonging to the client (such as its ephemeral ECDH public 912 key). 914 Structure of this message: 916 The TLS ClientKeyExchange message is extended as follows. 918 enum { 919 implicit, 920 explicit 921 } PublicValueEncoding; 923 o implicit, explicit: For ECC cipher suites, this indicates whether 924 the client's ECDH public key is in the client's certificate 925 ("implicit") or is provided, as an ephemeral ECDH public key, in 926 the ClientKeyExchange message ("explicit"). The implicit encoding 927 is deprecated and is retained here for backward compatibility 928 only. 930 struct { 931 ECPoint ecdh_Yc; 932 } ClientECDiffieHellmanPublic; 934 ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte 935 string ECPoint.point, which may represent an elliptic curve point in 936 uncompressed format. 938 struct { 939 select (KeyExchangeAlgorithm) { 940 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 941 } exchange_keys; 942 } ClientKeyExchange; 944 Actions of the sender: 946 The client selects an ephemeral ECDH public key corresponding to the 947 parameters it received from the server. The format is the same as in 948 Section 5.4. 950 Actions of the receiver: 952 The server retrieves the client's ephemeral ECDH public key from the 953 ClientKeyExchange message and checks that it is on the same elliptic 954 curve as the server's ECDH key. 956 5.8. Certificate Verify 958 When this message is sent: 960 This message is sent when the client sends a client certificate 961 containing a public key usable for digital signatures. 963 Meaning of the message: 965 This message contains a signature that proves possession of the 966 private key corresponding to the public key in the client's 967 Certificate message. 969 Structure of this message: 971 The TLS CertificateVerify message and the underlying Signature type 972 are defined in the TLS base specifications, and the latter is 973 extended here in Section 5.4. For the ecdsa and eddsa cases, the 974 signature field in the CertificateVerify message contains an ECDSA or 975 EdDSA (respectively) signature computed over handshake messages 976 exchanged so far, exactly similar to CertificateVerify with other 977 signing algorithms: 979 CertificateVerify.signature.sha_hash 980 SHA(handshake_messages); 981 CertificateVerify.signature.rawdata 982 handshake_messages; 984 ECDSA signatures are computed as described in Section 5.10, and SHA 985 in the above template for sha_hash accordingly may denote a hash 986 algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature 987 consists of a pair of integers, r and s. The digitally-signed 988 element is encoded as an opaque vector <0..2^16-1>, the contents of 989 which are the DER encoding [CCITT.X690] corresponding to the 990 following ASN.1 notation [CCITT.X680]. 992 Ecdsa-Sig-Value ::= SEQUENCE { 993 r INTEGER, 994 s INTEGER 995 } 997 EdDSA signatures are generated and verified according to [RFC8032]. 998 The digitally-signed element is encoded as an opaque 999 vector<0..2^16-1>, the contents of which is the octet string output 1000 of the EdDSA signing algorithm. 1002 Actions of the sender: 1004 The client computes its signature over all handshake messages sent or 1005 received starting at client hello and up to but not including this 1006 message. It uses the private key corresponding to its certified 1007 public key to compute the signature, which is conveyed in the format 1008 defined above. 1010 Actions of the receiver: 1012 The server extracts the client's signature from the CertificateVerify 1013 message, and verifies the signature using the public key it received 1014 in the client's Certificate message. 1016 5.9. Elliptic Curve Certificates 1018 X.509 certificates containing ECC public keys or signed using ECDSA 1019 MUST comply with [RFC3279] or another RFC that replaces or extends 1020 it. X.509 certificates containing ECC public keys or signed using 1021 EdDSA MUST comply with [PKIX-EdDSA]. Clients SHOULD use the elliptic 1022 curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and 1023 SEC 2 [SECG-SEC2] or in [RFC8032]. 1025 EdDSA keys using the Ed25519 algorithm MUST use the ed25519 signature 1026 algorithm, and Ed448 keys MUST use the ed448 signature algorithm. 1027 This document does not define use of Ed25519ph and Ed448ph keys with 1028 TLS. Ed25519, Ed25519ph, Ed448, and Ed448ph keys MUST NOT be used 1029 with ECDSA. 1031 5.10. ECDH, ECDSA, and RSA Computations 1033 All ECDH calculations for the NIST curves (including parameter and 1034 key generation as well as the shared secret calculation) are 1035 performed according to [IEEE.P1363.1998] using the ECKAS-DH1 scheme 1036 with the identity map as key derivation function (KDF), so that the 1037 premaster secret is the x-coordinate of the ECDH shared secret 1038 elliptic curve point represented as an octet string. Note that this 1039 octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the 1040 Field Element to Octet String Conversion Primitive, has constant 1041 length for any given field; leading zeros found in this octet string 1042 MUST NOT be truncated. 1044 (Note that this use of the identity KDF is a technicality. The 1045 complete picture is that ECDH is employed with a non-trivial KDF 1046 because TLS does not directly use the premaster secret for anything 1047 other than for computing the master secret. In TLS 1.0 and 1.1, this 1048 means that the MD5- and SHA-1-based TLS PRF serves as a KDF; in TLS 1049 1.2 the KDF is determined by ciphersuite; it is conceivable that 1050 future TLS versions or new TLS extensions introduced in the future 1051 may vary this computation.) 1053 An ECDHE key exchange using X25519 (curve x25519) goes as follows: 1054 Each party picks a secret key d uniformly at random and computes the 1055 corresponding public key x = X25519(d, G). Parties exchange their 1056 public keys, and compute a shared secret as x_S = X25519(d, x_peer). 1057 If either party obtains all-zeroes x_S, it MUST abort the handshake 1058 (as required by definition of X25519 and X448). ECDHE for X448 works 1059 similarily, replacing X25519 with X448, and x25519 with x448. The 1060 derived shared secret is used directly as the premaster secret, which 1061 is always exactly 32 bytes when ECDHE with X25519 is used and 56 1062 bytes when ECDHE with X448 is used. 1064 All ECDSA computations MUST be performed according to ANSI X9.62 or 1065 its successors. Data to be signed/verified is hashed, and the result 1066 run directly through the ECDSA algorithm with no additional hashing. 1067 A secure hash function such as SHA-256, SHA-384, or SHA-512 from 1068 [FIPS.180-4] MUST be used. 1070 All EdDSA computations MUST be performed according to [RFC8032] or 1071 its succesors. Data to be signed/verified is run through the EdDSA 1072 algorithm wih no hashing (EdDSA will internally run the data through 1073 the PH function). The context parameter for Ed448 MUST be set to the 1074 empty string. 1076 RFC 4492 anticipated the standardization of a mechanism for 1077 specifying the required hash function in the certificate, perhaps in 1078 the parameters field of the subjectPublicKeyInfo. Such 1079 standardization never took place, and as a result, SHA-1 is used in 1080 TLS 1.1 and earlier (except for EdDSA, which uses identity function). 1081 TLS 1.2 added a SignatureAndHashAlgorithm parameter to the 1082 DigitallySigned struct, thus allowing agility in choosing the 1083 signature hash. EdDSA signatures MUST have HashAlgorithm of TBD5 1084 (Intrinsic). 1086 All RSA signatures must be generated and verified according to 1087 [PKCS1] block type 1. 1089 5.11. Public Key Validation 1091 With the NIST curves, each party MUST validate the public key sent by 1092 its peer in the ClientKeyExchange and ServerKeyExchange messages. A 1093 receiving party MUST check that the x and y parameters from the 1094 peer's public value satisfy the curve equation, y^2 = x^3 + ax + b 1095 mod p. See section 2.3 of [Menezes] for details. Failing to do so 1096 allows attackers to gain information about the private key, to the 1097 point that they may recover the entire private key in a few requests, 1098 if that key is not really ephemeral. 1100 With X25519 and X448, a receiving party MUST check whether the 1101 computed premaster secret is the all-zero value and abort the 1102 handshake if so, as described in section 6 of [RFC7748]. 1104 Ed25519 and Ed448 internally do public key validation as part of 1105 signature verification. 1107 6. Cipher Suites 1109 The table below defines new ECC cipher suites that use the key 1110 exchange algorithms specified in Section 2. 1112 +---------------------------------------+----------------+ 1113 | CipherSuite | Identifier | 1114 +---------------------------------------+----------------+ 1115 | TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } | 1116 | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } | 1117 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } | 1118 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } | 1119 | | | 1120 | TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } | 1121 | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } | 1122 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } | 1123 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } | 1124 | | | 1125 | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } | 1126 | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } | 1127 | TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } | 1128 | TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } | 1129 +---------------------------------------+----------------+ 1131 Table 3: TLS ECC cipher suites 1133 The key exchange method, cipher, and hash algorithm for each of these 1134 cipher suites are easily determined by examining the name. Ciphers 1135 (other than AES ciphers) and hash algorithms are defined in [RFC2246] 1136 and [RFC4346]. AES ciphers are defined in [RFC5246]. 1138 Server implementations SHOULD support all of the following cipher 1139 suites, and client implementations SHOULD support at least one of 1140 them: 1142 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 1143 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 1144 o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 1145 o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 1147 7. Implementation Status 1149 Both ECDHE and ECDSA with the NIST curves are widely implemented, 1150 supported in all major browsers and all widely used TLS libraries. 1151 ECDHE with Curve25519 is by now implemented in several browsers and 1152 several TLS libraries including OpenSSL. Curve448 and EdDSA have 1153 working, interoperable implementations, but are not yet as widely 1154 deployed. 1156 8. Security Considerations 1158 Security issues are discussed throughout this memo. 1160 For TLS handshakes using ECC cipher suites, the security 1161 considerations in appendices D of all three TLS base documemts apply 1162 accordingly. 1164 Security discussions specific to ECC can be found in 1165 [IEEE.P1363.1998] and [ANSI.X9-62.2005]. One important issue that 1166 implementers and users must consider is elliptic curve selection. 1167 Guidance on selecting an appropriate elliptic curve size is given in 1168 Table 1. Security considerations specific to X25519 and X448 are 1169 discussed in section 7 of [RFC7748]. 1171 Beyond elliptic curve size, the main issue is elliptic curve 1172 structure. As a general principle, it is more conservative to use 1173 elliptic curves with as little algebraic structure as possible. 1174 Thus, random curves are more conservative than special curves such as 1175 Koblitz curves, and curves over F_p with p random are more 1176 conservative than curves over F_p with p of a special form, and 1177 curves over F_p with p random are considered more conservative than 1178 curves over F_2^m as there is no choice between multiple fields of 1179 similar size for characteristic 2. 1181 Another issue is the potential for catastrophic failures when a 1182 single elliptic curve is widely used. In this case, an attack on the 1183 elliptic curve might result in the compromise of a large number of 1184 keys. Again, this concern may need to be balanced against efficiency 1185 and interoperability improvements associated with widely-used curves. 1186 Substantial additional information on elliptic curve choice can be 1187 found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]. 1189 The Introduction of [RFC8032] lists the security, performance, and 1190 operational advantages of EdDSA signatures over ECDSA signatures 1191 using the NIST curves. 1193 All of the key exchange algorithms defined in this document provide 1194 forward secrecy. Some of the deprecated key exchange algorithms do 1195 not. 1197 9. IANA Considerations 1199 [RFC4492], the predecessor of this document has already defined the 1200 IANA registries for the following: 1202 o Supported Groups Section 5.1 1203 o ECPointFormat Section 5.1 1204 o ECCurveType Section 5.4 1206 IANA is requested to prepend "TLS" to the names of the previous three 1207 registries. 1209 For each name space, this document defines the initial value 1210 assignments and defines a range of 256 values (NamedCurve) or eight 1211 values (ECPointFormat and ECCurveType) reserved for Private Use. The 1212 policy for any additional assignments is "Specification Required". 1213 The previous version of this document required IETF review. 1215 NOTE: IANA, please update the registries to reflect the new policy. 1217 NOTE: RFC editor please delete these two notes prior to publication. 1219 IANA, please update these two registries to refer to this document. 1221 IANA is requested to assigned the value 29 to x25519, and the value 1222 30 to x448 in the TLS Supported Groups Registry. This replaces the 1223 temporary registrations ecdh_x25519(29) and ecdh_x448(30). 1225 IANA is requested to assign two values from the TLS 1226 SignatureAlgorithm Registry with names ed25519(TBD3) and ed448(TBD4) 1227 with this document as reference. To keep compatibility with TLS 1.3, 1228 TBD3 should be 7, and TBD4 should be 8. 1230 IANA is requested to assign one value from the "TLS HashAlgorithm 1231 Registry" with name Intrinsic(TBD5) and this document as reference. 1232 To keep compatibility with TLS 1.3, TBD5 should be 8 and DTLS-OK 1233 should be set to true (Y). 1235 10. Acknowledgements 1237 Most of the text is this document is taken from [RFC4492], the 1238 predecessor of this document. The authors of that document were: 1240 o Simon Blake-Wilson 1241 o Nelson Bolyard 1242 o Vipul Gupta 1243 o Chris Hawk 1244 o Bodo Moeller 1246 In the predecessor document, the authors acknowledged the 1247 contributions of Bill Anderson and Tim Dierks. 1249 The author would like to thank Nikos Mavrogiannopoulos, Martin 1250 Thomson, and Tanja Lange for contributions to this document. 1252 11. Version History for This Draft 1254 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION 1256 Changes from draft-ietf-tls-rfc4492bis-03 to draft-nir-tls- 1257 rfc4492bis-05: 1259 o Add support for CFRG curves and signatures work. 1261 Changes from draft-ietf-tls-rfc4492bis-01 to draft-nir-tls- 1262 rfc4492bis-03: 1264 o Removed unused curves. 1265 o Removed unused point formats (all but uncompressed) 1267 Changes from draft-nir-tls-rfc4492bis-00 and draft-ietf-tls- 1268 rfc4492bis-00 to draft-nir-tls-rfc4492bis-01: 1270 o Merged errata 1271 o Removed ECDH_RSA and ECDH_ECDSA 1273 Changes from RFC 4492 to draft-nir-tls-rfc4492bis-00: 1275 o Added TLS 1.2 to references. 1276 o Moved RFC 4492 authors to acknowledgements. 1277 o Removed list of required reading for ECC. 1278 o Prepended "TLS" to the names of the three registries defined in 1279 the IANA Considerations section. 1281 12. References 1283 12.1. Normative References 1285 [ANSI.X9-62.2005] 1286 American National Standards Institute, "Public Key 1287 Cryptography for the Financial Services Industry, The 1288 Elliptic Curve Digital Signature Algorithm (ECDSA)", 1289 ANSI X9.62, 2005. 1291 [CCITT.X680] 1292 International Telephone and Telegraph Consultative 1293 Committee, "Abstract Syntax Notation One (ASN.1): 1294 Specification of basic notation", CCITT Recommendation 1295 X.680, July 2002. 1297 [CCITT.X690] 1298 International Telephone and Telegraph Consultative 1299 Committee, "ASN.1 encoding rules: Specification of basic 1300 encoding Rules (BER), Canonical encoding rules (CER) and 1301 Distinguished encoding rules (DER)", CCITT Recommendation 1302 X.690, July 2002. 1304 [FIPS.186-4] 1305 National Institute of Standards and Technology, "Digital 1306 Signature Standard", FIPS PUB 186-4, 2013, 1307 . 1310 [PKCS1] RSA Laboratories, "RSA Encryption Standard, Version 1.5", 1311 PKCS 1, November 1993. 1313 [PKIX-EdDSA] 1314 Josefsson, S. and J. Schaad, "Algorithm Identifiers for 1315 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 1316 use in the Internet X.509 Public Key Infrastructure", 1317 August 2016, . 1320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1321 Requirement Levels", BCP 14, RFC 2119, March 1997. 1323 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1324 RFC 2246, January 1999. 1326 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1327 Identifiers for the Internet X.509 Public Key 1328 Infrastructure Certificate and Certificate Revocation List 1329 (CRL) Profile", RFC 3279, April 2002. 1331 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1332 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1334 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1335 and T. Wright, "Transport Layer Security (TLS) 1336 Extensions", RFC 4366, April 2006. 1338 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1339 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1341 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1342 for Security", RFC 7748, January 2016. 1344 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1345 Signature Algorithm (EdDSA)", RFC 8032, January 2017. 1347 [SECG-SEC2] 1348 CECG, "Recommended Elliptic Curve Domain Parameters", 1349 SEC 2, 2000. 1351 12.2. Informative References 1353 [FIPS.180-4] 1354 National Institute of Standards and Technology, "Secure 1355 Hash Standard (SHS)", FIPS PUB 180-4, August 2015, 1356 . 1359 [I-D.ietf-tls-tls13] 1360 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1361 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 1362 October 2016. 1364 [IEEE.P1363.1998] 1365 Institute of Electrical and Electronics Engineers, 1366 "Standard Specifications for Public Key Cryptography", 1367 IEEE Draft P1363, 1998. 1369 [Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 1370 Diffie-Hellman Key Agreement Protocols", IACR Menezes2008, 1371 December 2008. 1373 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1374 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1375 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1377 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 1378 Ephemeral Parameters for Transport Layer Security (TLS)", 1379 RFC 7919, DOI 10.17487/RFC7919, August 2016, 1380 . 1382 Appendix A. Equivalent Curves (Informative) 1384 All of the NIST curves [FIPS.186-4] and several of the ANSI curves 1385 [ANSI.X9-62.2005] are equivalent to curves listed in Section 5.1.1. 1386 In the following table, multiple names in one row represent aliases 1387 for the same curve. 1389 Curve names chosen by different standards organizations 1391 +-----------+------------+------------+ 1392 | SECG | ANSI X9.62 | NIST | 1393 +-----------+------------+------------+ 1394 | sect163k1 | | NIST K-163 | 1395 | sect163r1 | | | 1396 | sect163r2 | | NIST B-163 | 1397 | sect193r1 | | | 1398 | sect193r2 | | | 1399 | sect233k1 | | NIST K-233 | 1400 | sect233r1 | | NIST B-233 | 1401 | sect239k1 | | | 1402 | sect283k1 | | NIST K-283 | 1403 | sect283r1 | | NIST B-283 | 1404 | sect409k1 | | NIST K-409 | 1405 | sect409r1 | | NIST B-409 | 1406 | sect571k1 | | NIST K-571 | 1407 | sect571r1 | | NIST B-571 | 1408 | secp160k1 | | | 1409 | secp160r1 | | | 1410 | secp160r2 | | | 1411 | secp192k1 | | | 1412 | secp192r1 | prime192v1 | NIST P-192 | 1413 | secp224k1 | | | 1414 | secp224r1 | | NIST P-224 | 1415 | secp256k1 | | | 1416 | secp256r1 | prime256v1 | NIST P-256 | 1417 | secp384r1 | | NIST P-384 | 1418 | secp521r1 | | NIST P-521 | 1419 +-----------+------------+------------+ 1421 Table 4: Equivalent curves defined by SECG, ANSI, and NIST 1423 Appendix B. Differences from RFC 4492 1425 o Added TLS 1.2 1426 o Merged Errata 1427 o Removed the ECDH key exchange algorithms: ECDH_RSA and ECDH_ECDSA 1428 o Deprecated a bunch of ciphersuites: 1430 TLS_ECDH_ECDSA_WITH_NULL_SHA 1431 TLS_ECDH_ECDSA_WITH_RC4_128_SHA 1432 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA 1433 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 1434 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 1435 TLS_ECDH_RSA_WITH_NULL_SHA 1436 TLS_ECDH_RSA_WITH_RC4_128_SHA 1437 TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA 1438 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 1439 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 1440 All the other RC4 ciphersuites 1442 Removed unused curves and all but the uncompressed point format. 1444 Added X25519 and X448. 1446 Deprecated explicit curves. 1448 Removed restriction on signature algorithm in certificate. 1450 Authors' Addresses 1452 Yoav Nir 1453 Check Point Software Technologies Ltd. 1454 5 Hasolelim st. 1455 Tel Aviv 6789735 1456 Israel 1458 Email: ynir.ietf@gmail.com 1460 Simon Josefsson 1461 SJD AB 1463 Email: simon@josefsson.org 1465 Manuel Pegourie-Gonnard 1466 Independent / PolarSSL 1468 Email: mpg@elzevir.fr