idnits 2.17.1 draft-ietf-tls-rfc4492bis-14.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 677 has weird spacing: '...rveType cur...' == Line 693 has weird spacing: '...ameters cur...' == Line 713 has weird spacing: '...HParams par...' == Line 808 has weird spacing: '...ionForm form;...' -- The document date (March 6, 2017) is 2601 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 183, 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 (==), 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 7, 2017 M. Pegourie-Gonnard 7 Independent / PolarSSL 8 March 6, 2017 10 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer 11 Security (TLS) Versions 1.2 and Earlier 12 draft-ietf-tls-rfc4492bis-14 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 7, 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 6 66 3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 7 68 5. Data Structures and Computations . . . . . . . . . . . . . . 8 69 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8 70 5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 9 71 5.1.2. Supported Point Formats Extension . . . . . . . . . . 11 72 5.1.3. The signature_algorithms Extension and EdDSA . . . . 11 73 5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 12 74 5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 13 75 5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 14 76 5.4.1. Uncompressed Point Format for NIST curves . . . . . . 17 77 5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 18 78 5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 19 79 5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 20 80 5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 21 81 5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 23 82 5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 23 83 5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 24 84 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 25 85 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 89 11. Version History for This Draft . . . . . . . . . . . . . . . 28 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 92 12.2. Informative References . . . . . . . . . . . . . . . . . 30 93 Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 31 94 Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 32 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 97 1. Introduction 99 This document describes additions to TLS to support ECC, applicable 100 to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246]. The 101 use of ECC in TLS 1.3 is defined in [I-D.ietf-tls-tls13], and is 102 explicitly out of scope for this document. In particular, this 103 document defines: 105 o the use of the Elliptic Curve Diffie-Hellman key agreement scheme 106 with ephemeral keys to establish the TLS premaster secret, and 107 o the use of ECDSA certificates for authentication of TLS peers. 109 The remainder of this document is organized as follows. Section 2 110 provides an overview of ECC-based key exchange algorithms for TLS. 111 Section 3 describes the use of ECC certificates for client 112 authentication. TLS extensions that allow a client to negotiate the 113 use of specific curves and point formats are presented in Section 4. 114 Section 5 specifies various data structures needed for an ECC-based 115 handshake, their encoding in TLS messages, and the processing of 116 those messages. Section 6 defines ECC-based cipher suites and 117 identifies a small subset of these as recommended for all 118 implementations of this specification. Section 8 discusses security 119 considerations. Section 9 describes IANA considerations for the name 120 spaces created by this document's predecessor. Section 10 gives 121 acknowledgements. Appendix B provides differences from [RFC4492], 122 the document that this one replaces. 124 Implementation of this specification requires familiarity with TLS, 125 TLS extensions [RFC4366], and ECC. 127 1.1. Conventions Used in This Document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2. Key Exchange Algorithm 135 This document defines three new ECC-based key exchange algorithms for 136 TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS 137 premaster secret, and they differ only in the mechanism (if any) used 138 to authenticate them. The derivation of the TLS master secret from 139 the premaster secret and the subsequent generation of bulk 140 encryption/MAC keys and initialization vectors is independent of the 141 key exchange algorithm and not impacted by the introduction of ECC. 143 Table 1 summarizes the new key exchange algorithms. All of these key 144 exchange algorithms provide forward secrecy. 146 +-------------+------------------------------------------------+ 147 | Algorithm | Description | 148 +-------------+------------------------------------------------+ 149 | ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. | 150 | ECDHE_RSA | Ephemeral ECDH with RSA signatures. | 151 | ECDH_anon | Anonymous ephemeral ECDH, no signatures. | 152 +-------------+------------------------------------------------+ 154 Table 1: ECC Key Exchange Algorithms 156 These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, 157 respectively. 159 With ECDHE_RSA, a server can reuse its existing RSA certificate and 160 easily comply with a constrained client's elliptic curve preferences 161 (see Section 4). However, the computational cost incurred by a 162 server is higher for ECDHE_RSA than for the traditional RSA key 163 exchange, which does not provide forward secrecy. 165 The anonymous key exchange algorithm does not provide authentication 166 of the server or the client. Like other anonymous TLS key exchanges, 167 it is subject to man-in-the-middle attacks. Applications using TLS 168 with this algorithm SHOULD provide authentication by other means. 170 Client Server 171 ------ ------ 172 ClientHello --------> 173 ServerHello 174 Certificate* 175 ServerKeyExchange* 176 CertificateRequest*+ 177 <-------- ServerHelloDone 178 Certificate*+ 179 ClientKeyExchange 180 CertificateVerify*+ 181 [ChangeCipherSpec] 182 Finished --------> 183 [ChangeCipherSpec] 184 <-------- Finished 185 Application Data <-------> Application Data 186 * message is not sent under some conditions 187 + message is not sent unless client authentication 188 is desired 190 Figure 1: Message flow in a full TLS 1.2 handshake 192 Figure 1 shows all messages involved in the TLS key establishment 193 protocol (aka full handshake). The addition of ECC has direct impact 194 only on the ClientHello, the ServerHello, the server's Certificate 195 message, the ServerKeyExchange, the ClientKeyExchange, the 196 CertificateRequest, the client's Certificate message, and the 197 CertificateVerify. Next, we describe the ECC key exchange algorithm 198 in greater detail in terms of the content and processing of these 199 messages. For ease of exposition, we defer discussion of client 200 authentication and associated messages (identified with a + in 201 Figure 1) until Section 3 and of the optional ECC-specific extensions 202 (which impact the Hello messages) until Section 4. 204 2.1. ECDHE_ECDSA 206 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- or 207 EdDSA-capable public key. 209 The server sends its ephemeral ECDH public key and a specification of 210 the corresponding curve in the ServerKeyExchange message. These 211 parameters MUST be signed with ECDSA or EdDSA using the private key 212 corresponding to the public key in the server's Certificate. 214 The client generates an ECDH key pair on the same curve as the 215 server's ephemeral ECDH key and sends its public key in the 216 ClientKeyExchange message. 218 Both client and server perform an ECDH operation Section 5.10 and use 219 the resultant shared secret as the premaster secret. 221 2.2. ECDHE_RSA 223 This key exchange algorithm is the same as ECDHE_ECDSA except that 224 the server's certificate MUST contain an RSA public key authorized 225 for signing, and that the signature in the ServerKeyExchange message 226 must be computed with the corresponding RSA private key. 228 2.3. ECDH_anon 230 NOTE: Despite the name beginning with "ECDH_" (no E), the key used in 231 ECDH_anon is ephemeral just like the key in ECDHE_RSA and 232 ECDHE_ECDSA. The naming follows the example of DH_anon, where the 233 key is also ephemeral but the name does not reflect it. 235 In ECDH_anon, the server's Certificate, the CertificateRequest, the 236 client's Certificate, and the CertificateVerify messages MUST NOT be 237 sent. 239 The server MUST send an ephemeral ECDH public key and a specification 240 of the corresponding curve in the ServerKeyExchange message. These 241 parameters MUST NOT be signed. 243 The client generates an ECDH key pair on the same curve as the 244 server's ephemeral ECDH key and sends its public key in the 245 ClientKeyExchange message. 247 Both client and server perform an ECDH operation and use the 248 resultant shared secret as the premaster secret. All ECDH 249 calculations are performed as specified in Section 5.10. 251 This specification does not impose restrictions on signature schemes 252 used anywhere in the certificate chain. The previous version of this 253 document required the signatures to match, but this restriction, 254 originating in previous TLS versions is lifted here as it had been in 255 RFC 5246. 257 3. Client Authentication 259 This document defines a client authentication mechanism, named after 260 the type of client certificate involved: ECDSA_sign. The ECDSA_sign 261 mechanism is usable with any of the non-anonymous ECC key exchange 262 algorithms described in Section 2 as well as other non-anonymous 263 (non-ECC) key exchange algorithms defined in TLS. 265 Note that client certificates with EdDSA public keys use this 266 mechanism. 268 The server can request ECC-based client authentication by including 269 this certificate type in its CertificateRequest message. The client 270 must check if it possesses a certificate appropriate for the method 271 suggested by the server and is willing to use it for authentication. 273 If these conditions are not met, the client should send a client 274 Certificate message containing no certificates. In this case, the 275 ClientKeyExchange should be sent as described in Section 2, and the 276 CertificateVerify should not be sent. If the server requires client 277 authentication, it may respond with a fatal handshake failure alert. 279 If the client has an appropriate certificate and is willing to use it 280 for authentication, it must send that certificate in the client's 281 Certificate message (as per Section 5.6) and prove possession of the 282 private key corresponding to the certified key. The process of 283 determining an appropriate certificate and proving possession is 284 different for each authentication mechanism and described below. 286 NOTE: It is permissible for a server to request (and the client to 287 send) a client certificate of a different type than the server 288 certificate. 290 3.1. ECDSA_sign 292 To use this authentication mechanism, the client MUST possess a 293 certificate containing an ECDSA- or EdDSA-capable public key. 295 The client proves possession of the private key corresponding to the 296 certified key by including a signature in the CertificateVerify 297 message as described in Section 5.8. 299 4. TLS Extensions for ECC 301 Two TLS extensions are defined in this specification: (i) the 302 Supported Elliptic Curves Extension, and (ii) the Supported Point 303 Formats Extension. These allow negotiating the use of specific 304 curves and point formats (e.g., compressed vs. uncompressed, 305 respectively) during a handshake starting a new session. These 306 extensions are especially relevant for constrained clients that may 307 only support a limited number of curves or point formats. They 308 follow the general approach outlined in [RFC4366]; message details 309 are specified in Section 5. The client enumerates the curves it 310 supports and the point formats it can parse by including the 311 appropriate extensions in its ClientHello message. The server 312 similarly enumerates the point formats it can parse by including an 313 extension in its ServerHello message. 315 A TLS client that proposes ECC cipher suites in its ClientHello 316 message SHOULD include these extensions. Servers implementing ECC 317 cipher suites MUST support these extensions, and when a client uses 318 these extensions, servers MUST NOT negotiate the use of an ECC cipher 319 suite unless they can complete the handshake while respecting the 320 choice of curves and compression techniques specified by the client. 321 This eliminates the possibility that a negotiated ECC handshake will 322 be subsequently aborted due to a client's inability to deal with the 323 server's EC key. 325 The client MUST NOT include these extensions in the ClientHello 326 message if it does not propose any ECC cipher suites. A client that 327 proposes ECC cipher suites may choose not to include these 328 extensions. In this case, the server is free to choose any one of 329 the elliptic curves or point formats listed in Section 5. That 330 section also describes the structure and processing of these 331 extensions in greater detail. 333 In the case of session resumption, the server simply ignores the 334 Supported Elliptic Curves Extension and the Supported Point Formats 335 Extension appearing in the current ClientHello message. These 336 extensions only play a role during handshakes negotiating a new 337 session. 339 5. Data Structures and Computations 341 This section specifies the data structures and computations used by 342 ECC-based key mechanisms specified in the previous three sections. 343 The presentation language used here is the same as that used in TLS. 344 Since this specification extends TLS, these descriptions should be 345 merged with those in the TLS specification and any others that extend 346 TLS. This means that enum types may not specify all possible values, 347 and structures with multiple formats chosen with a select() clause 348 may not indicate all possible cases. 350 5.1. Client Hello Extensions 352 This section specifies two TLS extensions that can be included with 353 the ClientHello message as described in [RFC4366], the Supported 354 Elliptic Curves Extension and the Supported Point Formats Extension. 356 When these extensions are sent: 358 The extensions SHOULD be sent along with any ClientHello message that 359 proposes ECC cipher suites. 361 Meaning of these extensions: 363 These extensions allow a client to enumerate the elliptic curves it 364 supports and/or the point formats it can parse. 366 Structure of these extensions: 368 The general structure of TLS extensions is described in [RFC4366], 369 and this specification adds two types to ExtensionType. 371 enum { 372 elliptic_curves(10), 373 ec_point_formats(11) 374 } ExtensionType; 376 o elliptic_curves (Supported Elliptic Curves Extension): Indicates 377 the set of elliptic curves supported by the client. For this 378 extension, the opaque extension_data field contains 379 EllipticCurveList. See Section 5.1.1 for details. 380 o ec_point_formats (Supported Point Formats Extension): Indicates 381 the set of point formats that the client can parse. For this 382 extension, the opaque extension_data field contains 383 ECPointFormatList. See Section 5.1.2 for details. 385 Actions of the sender: 387 A client that proposes ECC cipher suites in its ClientHello message 388 appends these extensions (along with any others), enumerating the 389 curves it supports and the point formats it can parse. Clients 390 SHOULD send both the Supported Elliptic Curves Extension and the 391 Supported Point Formats Extension. If the Supported Point Formats 392 Extension is indeed sent, it MUST contain the value 0 (uncompressed) 393 as one of the items in the list of point formats. 395 Actions of the receiver: 397 A server that receives a ClientHello containing one or both of these 398 extensions MUST use the client's enumerated capabilities to guide its 399 selection of an appropriate cipher suite. One of the proposed ECC 400 cipher suites must be negotiated only if the server can successfully 401 complete the handshake while using the curves and point formats 402 supported by the client (cf. Section 5.3 and Section 5.4). 404 NOTE: A server participating in an ECDHE_ECDSA key exchange may use 405 different curves for the ECDSA or EdDSA key in its certificate, and 406 for the ephemeral ECDH key in the ServerKeyExchange message. The 407 server MUST consider the extensions in both cases. 409 If a server does not understand the Supported Elliptic Curves 410 Extension, does not understand the Supported Point Formats Extension, 411 or is unable to complete the ECC handshake while restricting itself 412 to the enumerated curves and point formats, it MUST NOT negotiate the 413 use of an ECC cipher suite. Depending on what other cipher suites 414 are proposed by the client and supported by the server, this may 415 result in a fatal handshake failure alert due to the lack of common 416 cipher suites. 418 5.1.1. Supported Elliptic Curves Extension 420 RFC 4492 defined 25 different curves in the NamedCurve registry (now 421 renamed the "Supported Groups" registry, although the enumeration 422 below is still named NamedCurve) for use in TLS. Only three have 423 seen much use. This specification is deprecating the rest (with 424 numbers 1-22). This specification also deprecates the explicit 425 curves with identifiers 0xFF01 and 0xFF02. It also adds the new 426 curves defined in [RFC7748]. The end result is as follows: 428 enum { 429 deprecated(1..22), 430 secp256r1 (23), secp384r1 (24), secp521r1 (25), 431 ecdh_x25519(29), ecdh_x448(30), 432 reserved (0xFE00..0xFEFF), 433 deprecated(0xFF01..0xFF02), 434 (0xFFFF) 435 } NamedCurve; 437 Note that other specifications have since added other values to this 438 enumeration. Some of those values are not curves at all, but finite 439 field groups. See [RFC7919]. 441 secp256r1, etc: Indicates support of the corresponding named curve or 442 groups. The named curves secp256r1, secp384r1, and secp521r1 are 443 specified in SEC 2 [SECG-SEC2]. These curves are also recommended in 444 ANSI X9.62 [ANSI.X9-62.2005] and FIPS 186-4 [FIPS.186-4]. The rest 445 of this document refers to these three curves as the "NIST curves" 446 because they were originally standardized by the National Institute 447 of Standards and Technology. The curves ecdh_x25519 and ecdh_x448 448 are defined in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved 449 for private use. 451 The predecessor of this document also supported explicitly defined 452 prime and char2 curves, but these are deprecated by this 453 specification. 455 The NamedCurve name space is maintained by IANA. See Section 9 for 456 information on how new value assignments are added. 458 struct { 459 NamedCurve elliptic_curve_list<2..2^16-1> 460 } EllipticCurveList; 462 Items in elliptic_curve_list are ordered according to the client's 463 preferences (favorite choice first). 465 As an example, a client that only supports secp256r1 (aka NIST P-256; 466 value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) 467 and prefers to use secp256r1 would include a TLS extension consisting 468 of the following octets. Note that the first two octets indicate the 469 extension type (Supported Elliptic Curves Extension): 471 00 0A 00 06 00 04 00 17 00 18 473 5.1.2. Supported Point Formats Extension 475 enum { 476 uncompressed (0), 477 deprecated (1..2), 478 reserved (248..255) 479 } ECPointFormat; 480 struct { 481 ECPointFormat ec_point_format_list<1..2^8-1> 482 } ECPointFormatList; 484 Three point formats were included in the definition of ECPointFormat 485 above. This specification deprecates all but the uncompressed point 486 format. Implementations of this document MUST support the 487 uncompressed format for all of their supported curves, and MUST NOT 488 support other formats for curves defined in this specification. For 489 backwards compatibility purposes, the point format list extension 490 MUST still be included, and contain exactly one value: the 491 uncompressed point format (0). 493 The ECPointFormat name space is maintained by IANA. See Section 9 494 for information on how new value assignments are added. 496 Items in ec_point_format_list are ordered according to the client's 497 preferences (favorite choice first). 499 A client compliant with this specification that supports no other 500 curves MUST send the following octets; note that the first two octets 501 indicate the extension type (Supported Point Formats Extension): 503 00 0B 00 02 01 00 505 5.1.3. The signature_algorithms Extension and EdDSA 507 The signature_algorithms extension, defined in section 7.4.1.4.1 of 508 [RFC5246], advertises the combinations of signature algorithm and 509 hash function that the client supports. The pure (non pre-hashed) 510 forms of EdDSA do not hash the data before signing it. For this 511 reason it does not make sense to combine them with a signature 512 algorithm in the extension. 514 For bits-on-the-wire compatibility with TLS 1.3, we define a new 515 dummy value in the HashAlgorithm registry which we will call 516 "Intrinsic" (value TBD5) meaning that hashing is intrinsic to the 517 signature algorithm. 519 To represent ed25519 and ed448 in the signature_algorithms extension, 520 the value shall be (TBD5,TBD3) and (TBD5,TBD4) respectively. 522 5.2. Server Hello Extension 524 This section specifies a TLS extension that can be included with the 525 ServerHello message as described in [RFC4366], the Supported Point 526 Formats Extension. 528 When this extension is sent: 530 The Supported Point Formats Extension is included in a ServerHello 531 message in response to a ClientHello message containing the Supported 532 Point Formats Extension when negotiating an ECC cipher suite. 534 Meaning of this extension: 536 This extension allows a server to enumerate the point formats it can 537 parse (for the curve that will appear in its ServerKeyExchange 538 message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key 539 exchange algorithm. 541 Structure of this extension: 543 The server's Supported Point Formats Extension has the same structure 544 as the client's Supported Point Formats Extension (see 545 Section 5.1.2). Items in ec_point_format_list here are ordered 546 according to the server's preference (favorite choice first). Note 547 that the server MAY include items that were not found in the client's 548 list. However, without extensions this specification allows exactly 549 one point format, so there is not really any opportunity for 550 mismatches. 552 Actions of the sender: 554 A server that selects an ECC cipher suite in response to a 555 ClientHello message including a Supported Point Formats Extension 556 appends this extension (along with others) to its ServerHello 557 message, enumerating the point formats it can parse. The Supported 558 Point Formats Extension, when used, MUST contain the value 0 559 (uncompressed) as one of the items in the list of point formats. 561 Actions of the receiver: 563 A client that receives a ServerHello message containing a Supported 564 Point Formats Extension MUST respect the server's choice of point 565 formats during the handshake (cf. Section 5.6 and Section 5.7). If 566 no Supported Point Formats Extension is received with the 567 ServerHello, this is equivalent to an extension allowing only the 568 uncompressed point format. 570 5.3. Server Certificate 572 When this message is sent: 574 This message is sent in all non-anonymous ECC-based key exchange 575 algorithms. 577 Meaning of this message: 579 This message is used to authentically convey the server's static 580 public key to the client. The following table shows the server 581 certificate type appropriate for each key exchange algorithm. ECC 582 public keys MUST be encoded in certificates as described in 583 Section 5.9. 585 NOTE: The server's Certificate message is capable of carrying a chain 586 of certificates. The restrictions mentioned in Table 3 apply only to 587 the server's certificate (first in the chain). 589 +-------------+-----------------------------------------------------+ 590 | Algorithm | Server Certificate Type | 591 +-------------+-----------------------------------------------------+ 592 | ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable | 593 | | public key. | 594 | ECDHE_RSA | Certificate MUST contain an RSA public key | 595 | | authorized for use in digital signatures. | 596 +-------------+-----------------------------------------------------+ 598 Table 2: Server Certificate Types 600 Structure of this message: 602 Identical to the TLS Certificate format. 604 Actions of the sender: 606 The server constructs an appropriate certificate chain and conveys it 607 to the client in the Certificate message. If the client has used a 608 Supported Elliptic Curves Extension, the public key in the server's 609 certificate MUST respect the client's choice of elliptic curves; If 610 the client has used a Supported Point Formats Extension, both the 611 server's public key point and (in the case of an explicit curve) the 612 curve's base point MUST respect the client's choice of point formats. 613 (A server that cannot satisfy these requirements MUST NOT choose an 614 ECC cipher suite in its ServerHello message.) 616 Actions of the receiver: 618 The client validates the certificate chain, extracts the server's 619 public key, and checks that the key type is appropriate for the 620 negotiated key exchange algorithm. (A possible reason for a fatal 621 handshake failure is that the client's capabilities for handling 622 elliptic curves and point formats are exceeded; cf. Section 5.1.) 624 5.4. Server Key Exchange 626 When this message is sent: 628 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and 629 ECDH_anon key exchange algorithms. 631 Meaning of this message: 633 This message is used to convey the server's ephemeral ECDH public key 634 (and the corresponding elliptic curve domain parameters) to the 635 client. 637 The ECCCurveType enum used to have values for explicit prime and for 638 explicit char2 curves. Those values are now deprecated, so only one 639 value remains: 641 Structure of this message: 643 enum { 644 deprecated (1..2), 645 named_curve (3), 646 reserved(248..255) 647 } ECCurveType; 649 The value named_curve indicates that a named curve is used. This 650 option SHOULD be used when applicable. 652 Values 248 through 255 are reserved for private use. 654 The ECCurveType name space is maintained by IANA. See Section 9 for 655 information on how new value assignments are added. 657 RFC 4492 had a specification for an ECCurve structure and an 658 ECBasisType structure. Both of these are omitted now because they 659 were only used with the now deprecated explicit curves. 661 struct { 662 opaque point <1..2^8-1>; 663 } ECPoint; 665 point: This is the byte string representation of an elliptic curve 666 point following the conversion routine in Section 4.3.6 of 667 [ANSI.X9-62.2005]. This byte string may represent an elliptic curve 668 point in uncompressed, compressed, or hybrid format, but this 669 specification deprecates all but the uncompressed format. For the 670 NIST curves, the format is repeated in Section 5.4.1 for convenience. 671 For the X25519 and X448 curves, the only valid representation is the 672 one specified in [RFC7748] - a 32- or 56-octet representation of the 673 u value of the point. This structure MUST NOT be used with Ed25519 674 and Ed448 public keys. 676 struct { 677 ECCurveType curve_type; 678 select (curve_type) { 679 case named_curve: 680 NamedCurve namedcurve; 681 }; 682 } ECParameters; 684 curve_type: This identifies the type of the elliptic curve domain 685 parameters. 687 namedCurve: Specifies a recommended set of elliptic curve domain 688 parameters. All those values of NamedCurve are allowed that refer to 689 a curve capable of Diffie-Hellman. With the deprecation of the 690 explicit curves, this now includes all of the NamedCurve values. 692 struct { 693 ECParameters curve_params; 694 ECPoint public; 695 } ServerECDHParams; 697 curve_params: Specifies the elliptic curve domain parameters 698 associated with the ECDH public key. 700 public: The ephemeral ECDH public key. 702 The ServerKeyExchange message is extended as follows. 704 enum { 705 ec_diffie_hellman 706 } KeyExchangeAlgorithm; 708 o ec_diffie_hellman: Indicates the ServerKeyExchange message 709 contains an ECDH public key. 711 select (KeyExchangeAlgorithm) { 712 case ec_diffie_hellman: 713 ServerECDHParams params; 714 Signature signed_params; 715 } ServerKeyExchange; 717 o params: Specifies the ECDH public key and associated domain 718 parameters. 719 o signed_params: A hash of the params, with the signature 720 appropriate to that hash applied. The private key corresponding 721 to the certified public key in the server's Certificate message is 722 used for signing. 724 enum { 725 ecdsa(3), 726 ed25519(TBD3) 727 ed448(TBD4) 728 } SignatureAlgorithm; 729 select (SignatureAlgorithm) { 730 case ecdsa: 731 digitally-signed struct { 732 opaque sha_hash[sha_size]; 733 }; 734 case ed25519,ed448: 735 digitally-signed struct { 736 opaque rawdata[rawdata_size]; 737 }; 738 } Signature; 739 ServerKeyExchange.signed_params.sha_hash 740 SHA(ClientHello.random + ServerHello.random + 741 ServerKeyExchange.params); 742 ServerKeyExchange.signed_params.rawdata 743 ClientHello.random + ServerHello.random + 744 ServerKeyExchange.params; 746 NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange 747 algorithm and "anonymous" for ECDH_anon. These cases are defined in 748 TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA. 749 ECDSA signatures are generated and verified as described in 750 Section 5.10, and SHA in the above template for sha_hash accordingly 751 may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an 752 ECDSA signature consists of a pair of integers, r and s. The 753 digitally-signed element is encoded as an opaque vector <0..2^16-1>, 754 the contents of which are the DER encoding corresponding to the 755 following ASN.1 notation. 757 Ecdsa-Sig-Value ::= SEQUENCE { 758 r INTEGER, 759 s INTEGER 760 } 762 EdDSA signatures in both the protocol and in certificates that 763 conform to [PKIX-EdDSA] are generated and verified according to 764 [RFC8032]. The digitally-signed element is encoded as an opaque 765 vector<0..2^16-1>, the contents of which is the octet string output 766 of the EdDSA signing algorithm. 768 Actions of the sender: 770 The server selects elliptic curve domain parameters and an ephemeral 771 ECDH public key corresponding to these parameters according to the 772 ECKAS-DH1 scheme from IEEE 1363 [IEEE.P1363.1998]. It conveys this 773 information to the client in the ServerKeyExchange message using the 774 format defined above. 776 Actions of the receiver: 778 The client verifies the signature (when present) and retrieves the 779 server's elliptic curve domain parameters and ephemeral ECDH public 780 key from the ServerKeyExchange message. (A possible reason for a 781 fatal handshake failure is that the client's capabilities for 782 handling elliptic curves and point formats are exceeded; cf. 783 Section 5.1.) 785 5.4.1. Uncompressed Point Format for NIST curves 787 The following represents the wire format for representing ECPoint in 788 ServerKeyExchange records. The first octet of the representation 789 indicates the form, which may be compressed, uncompressed, or hybrid. 790 This specification supports only the uncompressed format for these 791 curves. This is followed by the binary representation of the X value 792 in "big-endian" or "network" format, followed by the binary 793 representation of the Y value in "big-endian" or "network" format. 794 There are no internal length markers, so each number representation 795 occupies as many octets as implied by the curve parameters. For 796 P-256 this means that each of X and Y use 32 octets, padded on the 797 left by zeros if necessary. For P-384 they take 48 octets each, and 798 for P-521 they take 66 octets each. 800 Here's a more formal representation: 802 enum { 803 uncompressed(4), 804 (255) 805 } PointConversionForm; 807 struct { 808 PointConversionForm form; 809 opaque X[coordinate_length]; 810 opaque Y[coordinate_length]; 811 } UncompressedPointRepresentation; 813 5.5. Certificate Request 815 When this message is sent: 817 This message is sent when requesting client authentication. 819 Meaning of this message: 821 The server uses this message to suggest acceptable client 822 authentication methods. 824 Structure of this message: 826 The TLS CertificateRequest message is extended as follows. 828 enum { 829 ecdsa_sign(64), 830 rsa_fixed_ecdh(65), 831 ecdsa_fixed_ecdh(66), 832 (255) 833 } ClientCertificateType; 835 o ecdsa_sign, etc.: Indicates that the server would like to use the 836 corresponding client authentication method specified in Section 3. 838 Actions of the sender: 840 The server decides which client authentication methods it would like 841 to use, and conveys this information to the client using the format 842 defined above. 844 Actions of the receiver: 846 The client determines whether it has a suitable certificate for use 847 with any of the requested methods and whether to proceed with client 848 authentication. 850 5.6. Client Certificate 852 When this message is sent: 854 This message is sent in response to a CertificateRequest when a 855 client has a suitable certificate and has decided to proceed with 856 client authentication. (Note that if the server has used a Supported 857 Point Formats Extension, a certificate can only be considered 858 suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and 859 ECDSA_fixed_ECDH authentication methods if the public key point 860 specified in it respects the server's choice of point formats. If no 861 Supported Point Formats Extension has been used, a certificate can 862 only be considered suitable for use with these authentication methods 863 if the point is represented in uncompressed point format.) 865 Meaning of this message: 867 This message is used to authentically convey the client's static 868 public key to the server. The following table summarizes what client 869 certificate types are appropriate for the ECC-based client 870 authentication mechanisms described in Section 3. ECC public keys 871 must be encoded in certificates as described in Section 5.9. 873 NOTE: The client's Certificate message is capable of carrying a chain 874 of certificates. The restrictions mentioned in Table 4 apply only to 875 the client's certificate (first in the chain). 877 +------------------+------------------------------------------------+ 878 | Client | Client Certificate Type | 879 | Authentication | | 880 | Method | | 881 +------------------+------------------------------------------------+ 882 | ECDSA_sign | Certificate MUST contain an ECDSA- or EdDSA- | 883 | | capable public key. | 884 | ECDSA_fixed_ECDH | Certificate MUST contain an ECDH-capable | 885 | | public key on the same elliptic curve as the | 886 | | server's long-term ECDH key. | 887 | RSA_fixed_ECDH | The same as ECDSA_fixed_ECDH. The codepoints | 888 | | meant different things, but due to changes in | 889 | | TLS 1.2, both mean the same thing now. | 890 +------------------+------------------------------------------------+ 892 Table 3: Client Certificate Types 894 Structure of this message: 896 Identical to the TLS client Certificate format. 898 Actions of the sender: 900 The client constructs an appropriate certificate chain, and conveys 901 it to the server in the Certificate message. 903 Actions of the receiver: 905 The TLS server validates the certificate chain, extracts the client's 906 public key, and checks that the key type is appropriate for the 907 client authentication method. 909 5.7. Client Key Exchange 911 When this message is sent: 913 This message is sent in all key exchange algorithms. If client 914 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 915 message is empty. Otherwise, it contains the client's ephemeral ECDH 916 public key. 918 Meaning of the message: 920 This message is used to convey ephemeral data relating to the key 921 exchange belonging to the client (such as its ephemeral ECDH public 922 key). 924 Structure of this message: 926 The TLS ClientKeyExchange message is extended as follows. 928 enum { 929 implicit, 930 explicit 931 } PublicValueEncoding; 933 o implicit, explicit: For ECC cipher suites, this indicates whether 934 the client's ECDH public key is in the client's certificate 935 ("implicit") or is provided, as an ephemeral ECDH public key, in 936 the ClientKeyExchange message ("explicit"). (This is "explicit" 937 in ECC cipher suites except when the client uses the 938 ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication 939 mechanism.) 940 struct { 941 select (PublicValueEncoding) { 942 case implicit: struct { }; 943 case explicit: ECPoint ecdh_Yc; 944 } ecdh_public; 945 } ClientECDiffieHellmanPublic; 946 o ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte 947 string ECPoint.point, which may represent an elliptic curve point 948 in uncompressed or compressed format. Curves eddsa_ed25519 and 949 eddsa_ed448 MUST NOT be used here. Here, the format MUST conform 950 to what the server has requested through a Supported Point Formats 951 Extension if this extension was used, and MUST be uncompressed if 952 this extension was not used. 954 struct { 955 select (KeyExchangeAlgorithm) { 956 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 957 } exchange_keys; 958 } ClientKeyExchange; 960 Actions of the sender: 962 The client selects an ephemeral ECDH public key corresponding to the 963 parameters it received from the server according to the ECKAS-DH1 964 scheme from IEEE 1363. It conveys this information to the client in 965 the ClientKeyExchange message using the format defined above. 967 Actions of the receiver: 969 The server retrieves the client's ephemeral ECDH public key from the 970 ClientKeyExchange message and checks that it is on the same elliptic 971 curve as the server's ECDH key. 973 5.8. Certificate Verify 975 When this message is sent: 977 This message is sent when the client sends a client certificate 978 containing a public key usable for digital signatures, e.g., when the 979 client is authenticated using the ECDSA_sign mechanism. 981 Meaning of the message: 983 This message contains a signature that proves possession of the 984 private key corresponding to the public key in the client's 985 Certificate message. 987 Structure of this message: 989 The TLS CertificateVerify message and the underlying Signature type 990 are defined in the TLS base specifications, and the latter is 991 extended here in Section 5.4. For the ecdsa and eddsa cases, the 992 signature field in the CertificateVerify message contains an ECDSA or 993 EdDSA (respectively) signature computed over handshake messages 994 exchanged so far, exactly similar to CertificateVerify with other 995 signing algorithms: 997 CertificateVerify.signature.sha_hash 998 SHA(handshake_messages); 999 CertificateVerify.signature.rawdata 1000 handshake_messages; 1002 ECDSA signatures are computed as described in Section 5.10, and SHA 1003 in the above template for sha_hash accordingly may denote a hash 1004 algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature 1005 consists of a pair of integers, r and s. The digitally-signed 1006 element is encoded as an opaque vector <0..2^16-1>, the contents of 1007 which are the DER encoding [CCITT.X690] corresponding to the 1008 following ASN.1 notation [CCITT.X680]. 1010 Ecdsa-Sig-Value ::= SEQUENCE { 1011 r INTEGER, 1012 s INTEGER 1013 } 1015 EdDSA signatures are generated and verified according to [RFC8032]. 1016 The digitally-signed element is encoded as an opaque 1017 vector<0..2^16-1>, the contents of which is the octet string output 1018 of the EdDSA signing algorithm. 1020 Actions of the sender: 1022 The client computes its signature over all handshake messages sent or 1023 received starting at client hello and up to but not including this 1024 message. It uses the private key corresponding to its certified 1025 public key to compute the signature, which is conveyed in the format 1026 defined above. 1028 Actions of the receiver: 1030 The server extracts the client's signature from the CertificateVerify 1031 message, and verifies the signature using the public key it received 1032 in the client's Certificate message. 1034 5.9. Elliptic Curve Certificates 1036 X.509 certificates containing ECC public keys or signed using ECDSA 1037 MUST comply with [RFC3279] or another RFC that replaces or extends 1038 it. X.509 certificates containing ECC public keys or signed using 1039 EdDSA MUST comply with [PKIX-EdDSA]. Clients SHOULD use the elliptic 1040 curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and 1041 SEC 2 [SECG-SEC2] or in [RFC8032]. 1043 EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the 1044 eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the 1045 eddsa_ed448 curve. Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and 1046 eddsa_ed448 MUST NOT be used for ECDSA. 1048 5.10. ECDH, ECDSA, and RSA Computations 1050 All ECDH calculations for the NIST curves (including parameter and 1051 key generation as well as the shared secret calculation) are 1052 performed according to [IEEE.P1363.1998] using the ECKAS-DH1 scheme 1053 with the identity map as key derivation function (KDF), so that the 1054 premaster secret is the x-coordinate of the ECDH shared secret 1055 elliptic curve point represented as an octet string. Note that this 1056 octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the 1057 Field Element to Octet String Conversion Primitive, has constant 1058 length for any given field; leading zeros found in this octet string 1059 MUST NOT be truncated. 1061 (Note that this use of the identity KDF is a technicality. The 1062 complete picture is that ECDH is employed with a non-trivial KDF 1063 because TLS does not directly use the premaster secret for anything 1064 other than for computing the master secret. In TLS 1.0 and 1.1, this 1065 means that the MD5- and SHA-1-based TLS PRF serves as a KDF; in TLS 1066 1.2 the KDF is determined by ciphersuite; it is conceivable that 1067 future TLS versions or new TLS extensions introduced in the future 1068 may vary this computation.) 1070 An ECDHE key exchange using X25519 (curve ecdh_x25519) goes as 1071 follows: Each party picks a secret key d uniformly at random and 1072 computes the corresponding public key x = X25519(d, G). Parties 1073 exchange their public keys, and compute a shared secret as x_S = 1074 X25519(d, x_peer). If either party obtains all-zeroes x_S, it MUST 1075 abort the handshake (as required by definition of X25519 and X448). 1076 ECDHE for X448 works similarily, replacing X25519 with X448, and 1077 ecdh_x25519 with ecdh_x448. The derived shared secret is used 1078 directly as the premaster secret, which is always exactly 32 bytes 1079 when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is 1080 used. 1082 All ECDSA computations MUST be performed according to ANSI X9.62 or 1083 its successors. Data to be signed/verified is hashed, and the result 1084 run directly through the ECDSA algorithm with no additional hashing. 1085 The default hash function is SHA-1 [FIPS.180-2], and sha_size (see 1086 Section 5.4 and Section 5.8) is 20. However, an alternative hash 1087 function, such as one of the new SHA hash functions specified in FIPS 1088 180-2 [FIPS.180-2], SHOULD be used instead. 1090 All EdDSA computations MUST be performed according to [RFC8032] or 1091 its succesors. Data to be signed/verified is run through the EdDSA 1092 algorithm wih no hashing (EdDSA will internally run the data through 1093 the PH function). The context parameter for Ed448 MUST be set to the 1094 empty string. 1096 RFC 4492 anticipated the standardization of a mechanism for 1097 specifying the required hash function in the certificate, perhaps in 1098 the parameters field of the subjectPublicKeyInfo. Such 1099 standardization never took place, and as a result, SHA-1 is used in 1100 TLS 1.1 and earlier (except for EdDSA, which uses identity function). 1101 TLS 1.2 added a SignatureAndHashAlgorithm parameter to the 1102 DigitallySigned struct, thus allowing agility in choosing the 1103 signature hash. EdDSA signatures MUST have HashAlgorithm of TBD5 1104 (Intrinsic). 1106 All RSA signatures must be generated and verified according to 1107 [PKCS1] block type 1. 1109 5.11. Public Key Validation 1111 With the NIST curves, each party must validate the public key sent by 1112 its peer. A receiving party MUST check that the x and y parameters 1113 from the peer's public value satisfy the curve equation, y^2 = x^3 + 1114 ax + b mod p. See section 2.3 of [Menezes] for details. Failing to 1115 do so allows attackers to gain information about the private key, to 1116 the point that they may recover the entire private key in a few 1117 requests, if that key is not really ephemeral. 1119 X25519 was designed in a way that the result of X25519(x, d) will 1120 never reveal information about d, provided it was chosen as 1121 prescribed, for any value of x (the same holds true for X448). 1123 All-zeroes output from X25519 or X448 MUST NOT be used for premaster 1124 secret (as required by definition of X25519 and X448). If the 1125 premaster secret would be all zeroes, the handshake MUST be aborted 1126 (most probably by sending a fatal alert). 1128 Let's define legitimate values of x as the values that can be 1129 obtained as x = X25519(G, d') for some d', and call the other values 1130 illegitimate. The definition of the X25519 function shows that 1131 legitimate values all share the following property: the high-order 1132 bit of the last byte is not set (for X448, any bit can be set). 1134 Since there are some implementation of the X25519 function that 1135 impose this restriction on their input and others that don't, 1136 implementations of X25519 in TLS SHOULD reject public keys when the 1137 high-order bit of the final byte is set (in other words, when the 1138 value of the rightmost byte is greater than 0x7F) in order to prevent 1139 implementation fingerprinting. Note that this deviates from RFC 7748 1140 which suggests that This value be masked. 1142 Ed25519 and Ed448 internally do public key validation as part of 1143 signature verification. 1145 Other than this recommended check, implementations do not need to 1146 ensure that the public keys they receive are legitimate: this is not 1147 necessary for security with X25519. 1149 6. Cipher Suites 1151 The table below defines new ECC cipher suites that use the key 1152 exchange algorithms specified in Section 2. 1154 +---------------------------------------+----------------+ 1155 | CipherSuite | Identifier | 1156 +---------------------------------------+----------------+ 1157 | TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } | 1158 | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } | 1159 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } | 1160 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } | 1161 | | | 1162 | TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } | 1163 | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } | 1164 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } | 1165 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } | 1166 | | | 1167 | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } | 1168 | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } | 1169 | TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } | 1170 | TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } | 1171 +---------------------------------------+----------------+ 1173 Table 4: TLS ECC cipher suites 1175 The key exchange method, cipher, and hash algorithm for each of these 1176 cipher suites are easily determined by examining the name. Ciphers 1177 (other than AES ciphers) and hash algorithms are defined in [RFC2246] 1178 and [RFC4346]. AES ciphers are defined in [RFC5246]. 1180 Server implementations SHOULD support all of the following cipher 1181 suites, and client implementations SHOULD support at least one of 1182 them: 1184 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 1185 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 1186 o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 1187 o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 1189 7. Implementation Status 1191 Both ECDHE and ECDSA with the NIST curves are widely implemented, 1192 supported in all major browsers and all widely used TLS libraries. 1193 ECDHE with Curve25519 is by now implemented in several browsers and 1194 several TLS libraries including OpenSSL. Curve448 and EdDSA have 1195 working, interoperable implementations, but are not yet as widely 1196 deployed. 1198 8. Security Considerations 1200 Security issues are discussed throughout this memo. 1202 For TLS handshakes using ECC cipher suites, the security 1203 considerations in appendices D of all three TLS base documemts apply 1204 accordingly. 1206 Security discussions specific to ECC can be found in 1207 [IEEE.P1363.1998] and [ANSI.X9-62.2005]. One important issue that 1208 implementers and users must consider is elliptic curve selection. 1209 Guidance on selecting an appropriate elliptic curve size is given in 1210 Table 1. Security considerations specific to X25519 and X448 are 1211 discussed in section 7 of [RFC7748]. 1213 Beyond elliptic curve size, the main issue is elliptic curve 1214 structure. As a general principle, it is more conservative to use 1215 elliptic curves with as little algebraic structure as possible. 1216 Thus, random curves are more conservative than special curves such as 1217 Koblitz curves, and curves over F_p with p random are more 1218 conservative than curves over F_p with p of a special form, and 1219 curves over F_p with p random are considered more conservative than 1220 curves over F_2^m as there is no choice between multiple fields of 1221 similar size for characteristic 2. 1223 Another issue is the potential for catastrophic failures when a 1224 single elliptic curve is widely used. In this case, an attack on the 1225 elliptic curve might result in the compromise of a large number of 1226 keys. Again, this concern may need to be balanced against efficiency 1227 and interoperability improvements associated with widely-used curves. 1228 Substantial additional information on elliptic curve choice can be 1229 found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]. 1231 The Introduction of [RFC8032] lists the security, performance, and 1232 operational advantages of EdDSA signatures over ECDSA signatures 1233 using the NIST curves. 1235 All of the key exchange algorithms defined in this document provide 1236 forward secrecy. Some of the deprecated key exchange algorithms do 1237 not. 1239 9. IANA Considerations 1241 [RFC4492], the predecessor of this document has already defined the 1242 IANA registries for the following: 1244 o Supported Groups Section 5.1 1245 o ECPointFormat Section 5.1 1246 o ECCurveType Section 5.4 1248 IANA is requested to prepend "TLS" to the names of the previous three 1249 registries. 1251 For each name space, this document defines the initial value 1252 assignments and defines a range of 256 values (NamedCurve) or eight 1253 values (ECPointFormat and ECCurveType) reserved for Private Use. The 1254 policy for any additional assignments is "Specification Required". 1255 The previous version of this document required IETF review. 1257 NOTE: IANA, please update the registries to reflect the new policy. 1259 NOTE: RFC editor please delete these two notes prior to publication. 1261 IANA, please update these two registries to refer to this document. 1263 IANA has already assigned the value 29 to ecdh_x25519, and the value 1264 30 to ecdh_x448. 1266 IANA is requested to assign two values from the TLS 1267 SignatureAlgorithm Registry with names ed25519(TBD3) and ed448(TBD4) 1268 with this document as reference. To keep compatibility with TLS 1.3, 1269 TBD3 should be 7, and TBD4 should be 8. 1271 IANA is requested to assign one value from the "TLS HashAlgorithm 1272 Registry" with name Intrinsic(TBD5) and this document as reference. 1274 To keep compatibility with TLS 1.3, TBD5 should be 8 and DTLS-OK 1275 should be set to true (Y). 1277 10. Acknowledgements 1279 Most of the text is this document is taken from [RFC4492], the 1280 predecessor of this document. The authors of that document were: 1282 o Simon Blake-Wilson 1283 o Nelson Bolyard 1284 o Vipul Gupta 1285 o Chris Hawk 1286 o Bodo Moeller 1288 In the predecessor document, the authors acknowledged the 1289 contributions of Bill Anderson and Tim Dierks. 1291 The author would like to thank Nikos Mavrogiannopoulos, Martin 1292 Thomson, and Tanja Lange for contributions to this document. 1294 11. Version History for This Draft 1296 NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION 1298 Changes from draft-ietf-tls-rfc4492bis-03 to draft-nir-tls- 1299 rfc4492bis-05: 1301 o Add support for CFRG curves and signatures work. 1303 Changes from draft-ietf-tls-rfc4492bis-01 to draft-nir-tls- 1304 rfc4492bis-03: 1306 o Removed unused curves. 1307 o Removed unused point formats (all but uncompressed) 1309 Changes from draft-nir-tls-rfc4492bis-00 and draft-ietf-tls- 1310 rfc4492bis-00 to draft-nir-tls-rfc4492bis-01: 1312 o Merged errata 1313 o Removed ECDH_RSA and ECDH_ECDSA 1315 Changes from RFC 4492 to draft-nir-tls-rfc4492bis-00: 1317 o Added TLS 1.2 to references. 1318 o Moved RFC 4492 authors to acknowledgements. 1319 o Removed list of required reading for ECC. 1320 o Prepended "TLS" to the names of the three registries defined in 1321 the IANA Considerations section. 1323 12. References 1325 12.1. Normative References 1327 [ANSI.X9-62.2005] 1328 American National Standards Institute, "Public Key 1329 Cryptography for the Financial Services Industry, The 1330 Elliptic Curve Digital Signature Algorithm (ECDSA)", 1331 ANSI X9.62, 2005. 1333 [CCITT.X680] 1334 International Telephone and Telegraph Consultative 1335 Committee, "Abstract Syntax Notation One (ASN.1): 1336 Specification of basic notation", CCITT Recommendation 1337 X.680, July 2002. 1339 [CCITT.X690] 1340 International Telephone and Telegraph Consultative 1341 Committee, "ASN.1 encoding rules: Specification of basic 1342 encoding Rules (BER), Canonical encoding rules (CER) and 1343 Distinguished encoding rules (DER)", CCITT Recommendation 1344 X.690, July 2002. 1346 [FIPS.186-4] 1347 National Institute of Standards and Technology, "Digital 1348 Signature Standard", FIPS PUB 186-4, 2013, 1349 . 1352 [PKCS1] RSA Laboratories, "RSA Encryption Standard, Version 1.5", 1353 PKCS 1, November 1993. 1355 [PKIX-EdDSA] 1356 Josefsson, S. and J. Schaad, "Algorithm Identifiers for 1357 Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for 1358 use in the Internet X.509 Public Key Infrastructure", 1359 August 2016, . 1362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1363 Requirement Levels", BCP 14, RFC 2119, March 1997. 1365 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 1366 RFC 2246, January 1999. 1368 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 1369 Identifiers for the Internet X.509 Public Key 1370 Infrastructure Certificate and Certificate Revocation List 1371 (CRL) Profile", RFC 3279, April 2002. 1373 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1374 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1376 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1377 and T. Wright, "Transport Layer Security (TLS) 1378 Extensions", RFC 4366, April 2006. 1380 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1381 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1383 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1384 for Security", RFC 7748, January 2016. 1386 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 1387 Signature Algorithm (EdDSA)", RFC 8032, January 2017. 1389 [SECG-SEC2] 1390 CECG, "Recommended Elliptic Curve Domain Parameters", 1391 SEC 2, 2000. 1393 12.2. Informative References 1395 [FIPS.180-2] 1396 National Institute of Standards and Technology, "Secure 1397 Hash Standard", FIPS PUB 180-2, August 2002, 1398 . 1401 [I-D.ietf-tls-tls13] 1402 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1403 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 1404 October 2016. 1406 [IEEE.P1363.1998] 1407 Institute of Electrical and Electronics Engineers, 1408 "Standard Specifications for Public Key Cryptography", 1409 IEEE Draft P1363, 1998. 1411 [Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In 1412 Diffie-Hellman Key Agreement Protocols", IACR Menezes2008, 1413 December 2008. 1415 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 1416 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 1417 for Transport Layer Security (TLS)", RFC 4492, May 2006. 1419 [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman 1420 Ephemeral Parameters for Transport Layer Security (TLS)", 1421 RFC 7919, DOI 10.17487/RFC7919, August 2016, 1422 . 1424 Appendix A. Equivalent Curves (Informative) 1426 All of the NIST curves [FIPS.186-4] and several of the ANSI curves 1427 [ANSI.X9-62.2005] are equivalent to curves listed in Section 5.1.1. 1428 In the following table, multiple names in one row represent aliases 1429 for the same curve. 1431 Curve names chosen by different standards organizations 1433 +-----------+------------+------------+ 1434 | SECG | ANSI X9.62 | NIST | 1435 +-----------+------------+------------+ 1436 | sect163k1 | | NIST K-163 | 1437 | sect163r1 | | | 1438 | sect163r2 | | NIST B-163 | 1439 | sect193r1 | | | 1440 | sect193r2 | | | 1441 | sect233k1 | | NIST K-233 | 1442 | sect233r1 | | NIST B-233 | 1443 | sect239k1 | | | 1444 | sect283k1 | | NIST K-283 | 1445 | sect283r1 | | NIST B-283 | 1446 | sect409k1 | | NIST K-409 | 1447 | sect409r1 | | NIST B-409 | 1448 | sect571k1 | | NIST K-571 | 1449 | sect571r1 | | NIST B-571 | 1450 | secp160k1 | | | 1451 | secp160r1 | | | 1452 | secp160r2 | | | 1453 | secp192k1 | | | 1454 | secp192r1 | prime192v1 | NIST P-192 | 1455 | secp224k1 | | | 1456 | secp224r1 | | NIST P-224 | 1457 | secp256k1 | | | 1458 | secp256r1 | prime256v1 | NIST P-256 | 1459 | secp384r1 | | NIST P-384 | 1460 | secp521r1 | | NIST P-521 | 1461 +-----------+------------+------------+ 1463 Table 5: Equivalent curves defined by SECG, ANSI, and NIST 1465 Appendix B. Differences from RFC 4492 1467 o Added TLS 1.2 1468 o Merged Errata 1469 o Removed the ECDH key exchange algorithms: ECDH_RSA and ECDH_ECDSA 1470 o Deprecated a bunch of ciphersuites: 1472 TLS_ECDH_ECDSA_WITH_NULL_SHA 1473 TLS_ECDH_ECDSA_WITH_RC4_128_SHA 1474 TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA 1475 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 1476 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 1477 TLS_ECDH_RSA_WITH_NULL_SHA 1478 TLS_ECDH_RSA_WITH_RC4_128_SHA 1479 TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA 1480 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 1481 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 1482 All the other RC4 ciphersuites 1484 Removed unused curves and all but the uncompressed point format. 1486 Added X25519 and X448. 1488 Deprecated explicit curves. 1490 Removed restriction on signature algorithm in certificate. 1492 Authors' Addresses 1494 Yoav Nir 1495 Check Point Software Technologies Ltd. 1496 5 Hasolelim st. 1497 Tel Aviv 6789735 1498 Israel 1500 Email: ynir.ietf@gmail.com 1502 Simon Josefsson 1503 SJD AB 1505 Email: simon@josefsson.org 1507 Manuel Pegourie-Gonnard 1508 Independent / PolarSSL 1510 Email: mpg@elzevir.fr