From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8422.txt | 1907 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1907 insertions(+) create mode 100644 doc/rfc/rfc8422.txt (limited to 'doc/rfc/rfc8422.txt') diff --git a/doc/rfc/rfc8422.txt b/doc/rfc/rfc8422.txt new file mode 100644 index 0000000..422991f --- /dev/null +++ b/doc/rfc/rfc8422.txt @@ -0,0 +1,1907 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Nir +Request for Comments: 8422 Check Point +Obsoletes: 4492 S. Josefsson +Category: Standards Track SJD AB +ISSN: 2070-1721 M. Pegourie-Gonnard + ARM + August 2018 + + + Elliptic Curve Cryptography (ECC) Cipher Suites + for Transport Layer Security (TLS) Versions 1.2 and Earlier + +Abstract + + This document describes key exchange algorithms based on Elliptic + Curve Cryptography (ECC) for the Transport Layer Security (TLS) + protocol. In particular, it specifies the use of Ephemeral Elliptic + Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the + use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and + Edwards-curve Digital Signature Algorithm (EdDSA) as authentication + mechanisms. + + This document obsoletes RFC 4492. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8422. + + + + + + + + + + + + + + +Nir, et al. Standards Track [Page 1] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nir, et al. Standards Track [Page 2] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 + 2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 4 + 2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.4. Algorithms in Certificate Chains . . . . . . . . . . . . 7 + 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 8 + 3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 8 + 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 9 + 5. Data Structures and Computations . . . . . . . . . . . . . . 10 + 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 10 + 5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 11 + 5.1.2. Supported Point Formats Extension . . . . . . . . . . 13 + 5.1.3. The signature_algorithms Extension and EdDSA . . . . 13 + 5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 14 + 5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 15 + 5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 16 + 5.4.1. Uncompressed Point Format for NIST Curves . . . . . . 19 + 5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 20 + 5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 21 + 5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 22 + 5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 23 + 5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 24 + 5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 24 + 5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 26 + 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 26 + 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 10.2. Informative References . . . . . . . . . . . . . . . . . 31 + Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 32 + Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 33 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 + + + + + + + + + + + + +Nir, et al. Standards Track [Page 3] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +1. Introduction + + This document describes additions to TLS to support ECC that are + applicable to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 + [RFC5246]. The use of ECC in TLS 1.3 is defined in [TLS1.3] and is + explicitly out of scope for this document. In particular, this + document defines: + + o the use of the ECDHE key agreement scheme with ephemeral keys to + establish the TLS premaster secret, and + + o the use of ECDSA and EdDSA signatures for authentication of TLS + peers. + + The remainder of this document is organized as follows. Section 2 + provides an overview of ECC-based key exchange algorithms for TLS. + Section 3 describes the use of ECC certificates for client + authentication. TLS extensions that allow a client to negotiate the + use of specific curves and point formats are presented in Section 4. + Section 5 specifies various data structures needed for an ECC-based + handshake, their encoding in TLS messages, and the processing of + those messages. Section 6 defines ECC-based cipher suites and + identifies a small subset of these as recommended for all + implementations of this specification. Section 8 discusses security + considerations. Section 9 describes IANA considerations for the name + spaces created by this document's predecessor. Appendix B provides + differences from [RFC4492], the document that this one replaces. + + Implementation of this specification requires familiarity with TLS, + TLS extensions [RFC4366], and ECC. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Key Exchange Algorithm + + This document defines three new ECC-based key exchange algorithms for + TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS + premaster secret, and they differ only in the mechanism (if any) used + to authenticate them. The derivation of the TLS master secret from + the premaster secret and the subsequent generation of bulk + encryption/MAC keys and initialization vectors is independent of the + key exchange algorithm and not impacted by the introduction of ECC. + + + +Nir, et al. Standards Track [Page 4] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Table 1 summarizes the new key exchange algorithms. All of these key + exchange algorithms provide forward secrecy if and only if fresh + ephemeral keys are generated and used, and also destroyed after use. + + +-------------+------------------------------------------------+ + | Algorithm | Description | + +-------------+------------------------------------------------+ + | ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. | + | ECDHE_RSA | Ephemeral ECDH with RSA signatures. | + | ECDH_anon | Anonymous ephemeral ECDH, no signatures. | + +-------------+------------------------------------------------+ + + Table 1: ECC Key Exchange Algorithms + + These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, + respectively. + + With ECDHE_RSA, a server can reuse its existing RSA certificate and + easily comply with a constrained client's elliptic curve preferences + (see Section 4). However, the computational cost incurred by a + server is higher for ECDHE_RSA than for the traditional RSA key + exchange, which does not provide forward secrecy. + + The anonymous key exchange algorithm does not provide authentication + of the server or the client. Like other anonymous TLS key exchanges, + it is subject to man-in-the-middle attacks. Applications using TLS + with this algorithm SHOULD provide authentication by other means. + + + + + + + + + + + + + + + + + + + + + + + + +Nir, et al. Standards Track [Page 5] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Client Server + ------ ------ + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest*+ + <-------- ServerHelloDone + Certificate*+ + ClientKeyExchange + CertificateVerify*+ + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + * message is not sent under some conditions + + message is not sent unless client authentication + is desired + + Figure 1: Message Flow in a Full TLS 1.2 Handshake + + Figure 1 shows all messages involved in the TLS key establishment + protocol (aka full handshake). The addition of ECC has direct impact + only on the ClientHello, the ServerHello, the server's Certificate + message, the ServerKeyExchange, the ClientKeyExchange, the + CertificateRequest, the client's Certificate message, and the + CertificateVerify. Next, we describe the ECC key exchange algorithm + in greater detail in terms of the content and processing of these + messages. For ease of exposition, we defer discussion of client + authentication and associated messages (identified with a '+' in + Figure 1) until Section 3 and of the optional ECC-specific extensions + (which impact the Hello messages) until Section 4. + +2.1. ECDHE_ECDSA + + In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- or + EdDSA-capable public key. + + The server sends its ephemeral ECDH public key and a specification of + the corresponding curve in the ServerKeyExchange message. These + parameters MUST be signed with ECDSA or EdDSA using the private key + corresponding to the public key in the server's Certificate. + + The client generates an ECDH key pair on the same curve as the + server's ephemeral ECDH key and sends its public key in the + ClientKeyExchange message. + + + +Nir, et al. Standards Track [Page 6] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Both client and server perform an ECDH operation (see Section 5.10) + and use the resultant shared secret as the premaster secret. + +2.2. ECDHE_RSA + + This key exchange algorithm is the same as ECDHE_ECDSA except that + the server's certificate MUST contain an RSA public key authorized + for signing and the signature in the ServerKeyExchange message must + be computed with the corresponding RSA private key. + +2.3. ECDH_anon + + NOTE: Despite the name beginning with "ECDH_" (no E), the key used in + ECDH_anon is ephemeral just like the key in ECDHE_RSA and + ECDHE_ECDSA. The naming follows the example of DH_anon, where the + key is also ephemeral but the name does not reflect it. + + In ECDH_anon, the server's Certificate, the CertificateRequest, the + client's Certificate, and the CertificateVerify messages MUST NOT be + sent. + + The server MUST send an ephemeral ECDH public key and a specification + of the corresponding curve in the ServerKeyExchange message. These + parameters MUST NOT be signed. + + The client generates an ECDH key pair on the same curve as the + server's ephemeral ECDH key and sends its public key in the + ClientKeyExchange message. + + Both client and server perform an ECDH operation and use the + resultant shared secret as the premaster secret. All ECDH + calculations are performed as specified in Section 5.10. + +2.4. Algorithms in Certificate Chains + + This specification does not impose restrictions on signature schemes + used anywhere in the certificate chain. The previous version of this + document required the signatures to match, but this restriction, + originating in previous TLS versions, is lifted here as it had been + in RFC 5246. + + + + + + + + + + + +Nir, et al. Standards Track [Page 7] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +3. Client Authentication + + This document defines a client authentication mechanism named after + the type of client certificate involved: ECDSA_sign. The ECDSA_sign + mechanism is usable with any of the non-anonymous ECC key exchange + algorithms described in Section 2 as well as other non-anonymous + (non-ECC) key exchange algorithms defined in TLS. + + Note that client certificates with EdDSA public keys also use this + mechanism. + + The server can request ECC-based client authentication by including + this certificate type in its CertificateRequest message. The client + must check if it possesses a certificate appropriate for the method + suggested by the server and is willing to use it for authentication. + + If these conditions are not met, the client SHOULD send a client + Certificate message containing no certificates. In this case, the + ClientKeyExchange MUST be sent as described in Section 2, and the + CertificateVerify MUST NOT be sent. If the server requires client + authentication, it may respond with a fatal handshake failure alert. + + If the client has an appropriate certificate and is willing to use it + for authentication, it must send that certificate in the client's + Certificate message (as per Section 5.6) and prove possession of the + private key corresponding to the certified key. The process of + determining an appropriate certificate and proving possession is + different for each authentication mechanism and is described below. + + NOTE: It is permissible for a server to request (and the client to + send) a client certificate of a different type than the server + certificate. + +3.1. ECDSA_sign + + To use this authentication mechanism, the client MUST possess a + certificate containing an ECDSA- or EdDSA-capable public key. + + The client proves possession of the private key corresponding to the + certified key by including a signature in the CertificateVerify + message as described in Section 5.8. + + + + + + + + + + +Nir, et al. Standards Track [Page 8] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +4. TLS Extensions for ECC + + Two TLS extensions are defined in this specification: (i) the + Supported Elliptic Curves Extension and (ii) the Supported Point + Formats Extension. These allow negotiating the use of specific + curves and point formats (e.g., compressed vs. uncompressed, + respectively) during a handshake starting a new session. These + extensions are especially relevant for constrained clients that may + only support a limited number of curves or point formats. They + follow the general approach outlined in [RFC4366]; message details + are specified in Section 5. The client enumerates the curves it + supports and the point formats it can parse by including the + appropriate extensions in its ClientHello message. The server + similarly enumerates the point formats it can parse by including an + extension in its ServerHello message. + + A TLS client that proposes ECC cipher suites in its ClientHello + message SHOULD include these extensions. Servers implementing ECC + cipher suites MUST support these extensions, and when a client uses + these extensions, servers MUST NOT negotiate the use of an ECC cipher + suite unless they can complete the handshake while respecting the + choice of curves specified by the client. This eliminates the + possibility that a negotiated ECC handshake will be subsequently + aborted due to a client's inability to deal with the server's EC key. + + The client MUST NOT include these extensions in the ClientHello + message if it does not propose any ECC cipher suites. A client that + proposes ECC cipher suites may choose not to include these + extensions. In this case, the server is free to choose any one of + the elliptic curves or point formats listed in Section 5. That + section also describes the structure and processing of these + extensions in greater detail. + + In the case of session resumption, the server simply ignores the + Supported Elliptic Curves Extension and the Supported Point Formats + Extension appearing in the current ClientHello message. These + extensions only play a role during handshakes negotiating a new + session. + + + + + + + + + + + + + +Nir, et al. Standards Track [Page 9] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +5. Data Structures and Computations + + This section specifies the data structures and computations used by + ECC-based key mechanisms specified in the previous three sections. + The presentation language used here is the same as that used in TLS. + Since this specification extends TLS, these descriptions should be + merged with those in the TLS specification and any others that extend + TLS. This means that enum types may not specify all possible values, + and structures with multiple formats chosen with a select() clause + may not indicate all possible cases. + +5.1. Client Hello Extensions + + This section specifies two TLS extensions that can be included with + the ClientHello message as described in [RFC4366]: the Supported + Elliptic Curves Extension and the Supported Point Formats Extension. + + When these extensions are sent: + + The extensions SHOULD be sent along with any ClientHello message that + proposes ECC cipher suites. + + Meaning of these extensions: + + These extensions allow a client to enumerate the elliptic curves it + supports and/or the point formats it can parse. + + Structure of these extensions: + + The general structure of TLS extensions is described in [RFC4366], + and this specification adds two types to ExtensionType. + + enum { + elliptic_curves(10), + ec_point_formats(11) + } ExtensionType; + + o elliptic_curves (Supported Elliptic Curves Extension): Indicates + the set of elliptic curves supported by the client. For this + extension, the opaque extension_data field contains + NamedCurveList. See Section 5.1.1 for details. + + o ec_point_formats (Supported Point Formats Extension): Indicates + the set of point formats that the client can parse. For this + extension, the opaque extension_data field contains + ECPointFormatList. See Section 5.1.2 for details. + + + + + +Nir, et al. Standards Track [Page 10] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Actions of the sender: + + A client that proposes ECC cipher suites in its ClientHello message + appends these extensions (along with any others), enumerating the + curves it supports and the point formats it can parse. Clients + SHOULD send both the Supported Elliptic Curves Extension and the + Supported Point Formats Extension. If the Supported Point Formats + Extension is indeed sent, it MUST contain the value 0 (uncompressed) + as one of the items in the list of point formats. + + Actions of the receiver: + + A server that receives a ClientHello containing one or both of these + extensions MUST use the client's enumerated capabilities to guide its + selection of an appropriate cipher suite. One of the proposed ECC + cipher suites must be negotiated only if the server can successfully + complete the handshake while using the curves and point formats + supported by the client (cf. Sections 5.3 and 5.4). + + NOTE: A server participating in an ECDHE_ECDSA key exchange may use + different curves for the ECDSA or EdDSA key in its certificate and + for the ephemeral ECDH key in the ServerKeyExchange message. The + server MUST consider the extensions in both cases. + + If a server does not understand the Supported Elliptic Curves + Extension, does not understand the Supported Point Formats Extension, + or is unable to complete the ECC handshake while restricting itself + to the enumerated curves and point formats, it MUST NOT negotiate the + use of an ECC cipher suite. Depending on what other cipher suites + are proposed by the client and supported by the server, this may + result in a fatal handshake failure alert due to the lack of common + cipher suites. + +5.1.1. Supported Elliptic Curves Extension + + RFC 4492 defined 25 different curves in the NamedCurve registry (now + renamed the "TLS Supported Groups" registry, although the enumeration + below is still named NamedCurve) for use in TLS. Only three have + seen much use. This specification is deprecating the rest (with + numbers 1-22). This specification also deprecates the explicit + + + + + + + + + + + +Nir, et al. Standards Track [Page 11] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + curves with identifiers 0xFF01 and 0xFF02. It also adds the new + curves defined in [RFC7748]. The end result is as follows: + + enum { + deprecated(1..22), + secp256r1 (23), secp384r1 (24), secp521r1 (25), + x25519(29), x448(30), + reserved (0xFE00..0xFEFF), + deprecated(0xFF01..0xFF02), + (0xFFFF) + } NamedCurve; + + Note that other specifications have since added other values to this + enumeration. Some of those values are not curves at all, but finite + field groups. See [RFC7919]. + + secp256r1, etc: Indicates support of the corresponding named curve or + groups. The named curves secp256r1, secp384r1, and secp521r1 are + specified in SEC 2 [SECG-SEC2]. These curves are also recommended in + ANSI X9.62 [ANSI.X9-62.2005] and FIPS 186-4 [FIPS.186-4]. The rest + of this document refers to these three curves as the "NIST curves" + because they were originally standardized by the National Institute + of Standards and Technology. The curves x25519 and x448 are defined + in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for private + use. + + The predecessor of this document also supported explicitly defined + prime and char2 curves, but these are deprecated by this + specification. + + The NamedCurve name space (now titled "TLS Supported Groups") is + maintained by IANA. See Section 9 for information on how new value + assignments are added. + + struct { + NamedCurve named_curve_list<2..2^16-1> + } NamedCurveList; + + Items in named_curve_list are ordered according to the client's + preferences (favorite choice first). + + As an example, a client that only supports secp256r1 (aka NIST P-256; + value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) + and prefers to use secp256r1 would include a TLS extension consisting + of the following octets. Note that the first two octets indicate the + extension type (Supported Elliptic Curves Extension): + + 00 0A 00 06 00 04 00 17 00 18 + + + +Nir, et al. Standards Track [Page 12] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +5.1.2. Supported Point Formats Extension + + enum { + uncompressed (0), + deprecated (1..2), + reserved (248..255) + } ECPointFormat; + struct { + ECPointFormat ec_point_format_list<1..2^8-1> + } ECPointFormatList; + + Three point formats were included in the definition of ECPointFormat + above. This specification deprecates all but the uncompressed point + format. Implementations of this document MUST support the + uncompressed format for all of their supported curves and MUST NOT + support other formats for curves defined in this specification. For + backwards compatibility purposes, the point format list extension MAY + still be included and contain exactly one value: the uncompressed + point format (0). RFC 4492 specified that if this extension is + missing, it means that only the uncompressed point format is + supported, so interoperability with implementations that support the + uncompressed format should work with or without the extension. + + If the client sends the extension and the extension does not contain + the uncompressed point format, and the client has used the Supported + Groups extension to indicate support for any of the curves defined in + this specification, then the server MUST abort the handshake and + return an illegal_parameter alert. + + The ECPointFormat name space (now titled "TLS EC Point Formats") is + maintained by IANA. See Section 9 for information on how new value + assignments are added. + + A client compliant with this specification that supports no other + curves MUST send the following octets; note that the first two octets + indicate the extension type (Supported Point Formats Extension): + + 00 0B 00 02 01 00 + +5.1.3. The signature_algorithms Extension and EdDSA + + The signature_algorithms extension, defined in Section 7.4.1.4.1 of + [RFC5246], advertises the combinations of signature algorithm and + hash function that the client supports. The pure (non-prehashed) + forms of EdDSA do not hash the data before signing it. For this + reason, it does not make sense to combine them with a hash function + in the extension. + + + + +Nir, et al. Standards Track [Page 13] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + For bits-on-the-wire compatibility with TLS 1.3, we define a new + dummy value in the "TLS HashAlgorithm" registry that we call + "Intrinsic" (value 8), meaning that hashing is intrinsic to the + signature algorithm. + + To represent ed25519 and ed448 in the signature_algorithms extension, + the value shall be (8,7) and (8,8), respectively. + +5.2. Server Hello Extension + + This section specifies a TLS extension that can be included with the + ServerHello message as described in [RFC4366], the Supported Point + Formats Extension. + + When this extension is sent: + + The Supported Point Formats Extension is included in a ServerHello + message in response to a ClientHello message containing the Supported + Point Formats Extension when negotiating an ECC cipher suite. + + Meaning of this extension: + + This extension allows a server to enumerate the point formats it can + parse (for the curve that will appear in its ServerKeyExchange + message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key + exchange algorithm. + + Structure of this extension: + + The server's Supported Point Formats Extension has the same structure + as the client's Supported Point Formats Extension (see + Section 5.1.2). Items in ec_point_format_list here are ordered + according to the server's preference (favorite choice first). Note + that the server MAY include items that were not found in the client's + list. However, without extensions, this specification allows exactly + one point format, so there is not really any opportunity for + mismatches. + + Actions of the sender: + + A server that selects an ECC cipher suite in response to a + ClientHello message including a Supported Point Formats Extension + appends this extension (along with others) to its ServerHello + message, enumerating the point formats it can parse. The Supported + Point Formats Extension, when used, MUST contain the value 0 + (uncompressed) as one of the items in the list of point formats. + + + + + +Nir, et al. Standards Track [Page 14] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Actions of the receiver: + + A client that receives a ServerHello message containing a Supported + Point Formats Extension MUST respect the server's choice of point + formats during the handshake (cf. Sections 5.6 and 5.7). If no + Supported Point Formats Extension is received with the ServerHello, + this is equivalent to an extension allowing only the uncompressed + point format. + +5.3. Server Certificate + + When this message is sent: + + This message is sent in all non-anonymous, ECC-based key exchange + algorithms. + + Meaning of this message: + + This message is used to authentically convey the server's static + public key to the client. The following table shows the server + certificate type appropriate for each key exchange algorithm. ECC + public keys MUST be encoded in certificates as described in + Section 5.9. + + NOTE: The server's Certificate message is capable of carrying a chain + of certificates. The restrictions mentioned in Table 2 apply only to + the server's certificate (first in the chain). + + +-------------+-----------------------------------------------------+ + | Algorithm | Server Certificate Type | + +-------------+-----------------------------------------------------+ + | ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable | + | | public key. | + | ECDHE_RSA | Certificate MUST contain an RSA public key. | + +-------------+-----------------------------------------------------+ + + Table 2: Server Certificate Types + + Structure of this message: + + Identical to the TLS Certificate format. + + Actions of the sender: + + The server constructs an appropriate certificate chain and conveys it + to the client in the Certificate message. If the client has used a + Supported Elliptic Curves Extension, the public key in the server's + + + + +Nir, et al. Standards Track [Page 15] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + certificate MUST respect the client's choice of elliptic curves. A + server that cannot satisfy this requirement MUST NOT choose an ECC + cipher suite in its ServerHello message.) + + Actions of the receiver: + + The client validates the certificate chain, extracts the server's + public key, and checks that the key type is appropriate for the + negotiated key exchange algorithm. (A possible reason for a fatal + handshake failure is that the client's capabilities for handling + elliptic curves and point formats are exceeded; cf. Section 5.1.) + +5.4. Server Key Exchange + + When this message is sent: + + This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and + ECDH_anon key exchange algorithms. + + Meaning of this message: + + This message is used to convey the server's ephemeral ECDH public key + (and the corresponding elliptic curve domain parameters) to the + client. + + The ECCurveType enum used to have values for explicit prime and for + explicit char2 curves. Those values are now deprecated, so only one + value remains: + + Structure of this message: + + enum { + deprecated (1..2), + named_curve (3), + reserved(248..255) + } ECCurveType; + + The value named_curve indicates that a named curve is used. This + option is now the only remaining format. + + Values 248 through 255 are reserved for private use. + + The ECCurveType name space (now titled "TLS EC Curve Types") is + maintained by IANA. See Section 9 for information on how new value + assignments are added. + + + + + + +Nir, et al. Standards Track [Page 16] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + RFC 4492 had a specification for an ECCurve structure and an + ECBasisType structure. Both of these are omitted now because they + were only used with the now deprecated explicit curves. + + struct { + opaque point <1..2^8-1>; + } ECPoint; + + point: This is the byte string representation of an elliptic curve + point following the conversion routine in Section 4.3.6 of + [ANSI.X9-62.2005]. This byte string may represent an elliptic curve + point in uncompressed, compressed, or hybrid format, but this + specification deprecates all but the uncompressed format. For the + NIST curves, the format is repeated in Section 5.4.1 for convenience. + For the X25519 and X448 curves, the only valid representation is the + one specified in [RFC7748], a 32- or 56-octet representation of the u + value of the point. This structure MUST NOT be used with Ed25519 and + Ed448 public keys. + + struct { + ECCurveType curve_type; + select (curve_type) { + case named_curve: + NamedCurve namedcurve; + }; + } ECParameters; + + curve_type: This identifies the type of the elliptic curve domain + parameters. + + namedCurve: Specifies a recommended set of elliptic curve domain + parameters. All those values of NamedCurve are allowed that refer to + a curve capable of Diffie-Hellman. With the deprecation of the + explicit curves, this now includes all of the NamedCurve values. + + struct { + ECParameters curve_params; + ECPoint public; + } ServerECDHParams; + + curve_params: Specifies the elliptic curve domain parameters + associated with the ECDH public key. + + public: The ephemeral ECDH public key. + + + + + + + +Nir, et al. Standards Track [Page 17] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + The ServerKeyExchange message is extended as follows. + + enum { + ec_diffie_hellman + } KeyExchangeAlgorithm; + + o ec_diffie_hellman: Indicates the ServerKeyExchange message + contains an ECDH public key. + + select (KeyExchangeAlgorithm) { + case ec_diffie_hellman: + ServerECDHParams params; + Signature signed_params; + } ServerKeyExchange; + + o params: Specifies the ECDH public key and associated domain + parameters. + + o signed_params: A hash of the params, with the signature + appropriate to that hash applied. The private key corresponding + to the certified public key in the server's Certificate message is + used for signing. + + enum { + ecdsa(3), + ed25519(7) + ed448(8) + } SignatureAlgorithm; + select (SignatureAlgorithm) { + case ecdsa: + digitally-signed struct { + opaque sha_hash[sha_size]; + }; + case ed25519,ed448: + digitally-signed struct { + opaque rawdata[rawdata_size]; + }; + } Signature; + ServerKeyExchange.signed_params.sha_hash + SHA(ClientHello.random + ServerHello.random + + ServerKeyExchange.params); + ServerKeyExchange.signed_params.rawdata + ClientHello.random + ServerHello.random + + ServerKeyExchange.params; + + NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange + algorithm and "anonymous" for ECDH_anon. These cases are defined in + TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA. + + + +Nir, et al. Standards Track [Page 18] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + ECDSA signatures are generated and verified as described in + Section 5.10. SHA, in the above template for sha_hash, may denote a + hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA + signature consists of a pair of integers, r and s. The digitally- + signed element is encoded as an opaque vector <0..2^16-1>, the + contents of which are the DER encoding corresponding to the following + ASN.1 notation. + + Ecdsa-Sig-Value ::= SEQUENCE { + r INTEGER, + s INTEGER + } + + EdDSA signatures in both the protocol and in certificates that + conform to [RFC8410] are generated and verified according to + [RFC8032]. The digitally-signed element is encoded as an opaque + vector <0..2^16-1>, the contents of which include the octet string + output of the EdDSA signing algorithm. + + Actions of the sender: + + The server selects elliptic curve domain parameters and an ephemeral + ECDH public key corresponding to these parameters according to the + ECKAS-DH1 scheme from IEEE 1363 [IEEE.P1363]. It conveys this + information to the client in the ServerKeyExchange message using the + format defined above. + + Actions of the receiver: + + The client verifies the signature (when present) and retrieves the + server's elliptic curve domain parameters and ephemeral ECDH public + key from the ServerKeyExchange message. (A possible reason for a + fatal handshake failure is that the client's capabilities for + handling elliptic curves and point formats are exceeded; cf. + Section 5.1.) + +5.4.1. Uncompressed Point Format for NIST Curves + + The following represents the wire format for representing ECPoint in + ServerKeyExchange records. The first octet of the representation + indicates the form, which may be compressed, uncompressed, or hybrid. + This specification supports only the uncompressed format for these + curves. This is followed by the binary representation of the X value + in "big-endian" or "network" format, followed by the binary + representation of the Y value in "big-endian" or "network" format. + There are no internal length markers, so each number representation + occupies as many octets as implied by the curve parameters. For + + + + +Nir, et al. Standards Track [Page 19] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + P-256 this means that each of X and Y use 32 octets, padded on the + left by zeros if necessary. For P-384, they take 48 octets each, and + for P-521, they take 66 octets each. + + Here's a more formal representation: + + enum { + uncompressed(4), + (255) + } PointConversionForm; + + struct { + PointConversionForm form; + opaque X[coordinate_length]; + opaque Y[coordinate_length]; + } UncompressedPointRepresentation; + +5.5. Certificate Request + + When this message is sent: + + This message is sent when requesting client authentication. + + Meaning of this message: + + The server uses this message to suggest acceptable client + authentication methods. + + Structure of this message: + + The TLS CertificateRequest message is extended as follows. + + enum { + ecdsa_sign(64), + deprecated1(65), /* was rsa_fixed_ecdh */ + deprecated2(66), /* was ecdsa_fixed_ecdh */ + (255) + } ClientCertificateType; + + o ecdsa_sign: Indicates that the server would like to use the + corresponding client authentication method specified in Section 3. + + Note that RFC 4492 also defined RSA and ECDSA certificates that + included a fixed ECDH public key. These mechanisms saw very little + implementation, so this specification is deprecating them. + + + + + + +Nir, et al. Standards Track [Page 20] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Actions of the sender: + + The server decides which client authentication methods it would like + to use and conveys this information to the client using the format + defined above. + + Actions of the receiver: + + The client determines whether it has a suitable certificate for use + with any of the requested methods and whether to proceed with client + authentication. + +5.6. Client Certificate + + When this message is sent: + + This message is sent in response to a CertificateRequest when a + client has a suitable certificate and has decided to proceed with + client authentication. (Note that if the server has used a Supported + Point Formats Extension, a certificate can only be considered + suitable for use with the ECDSA_sign authentication method if the + public key point specified in it is uncompressed, as that is the only + point format still supported. + + Meaning of this message: + + This message is used to authentically convey the client's static + public key to the server. ECC public keys must be encoded in + certificates as described in Section 5.9. The certificate MUST + contain an ECDSA- or EdDSA-capable public key. + + NOTE: The client's Certificate message is capable of carrying a chain + of certificates. The restrictions mentioned above apply only to the + client's certificate (first in the chain). + + Structure of this message: + + Identical to the TLS client Certificate format. + + Actions of the sender: + + The client constructs an appropriate certificate chain and conveys it + to the server in the Certificate message. + + + + + + + + +Nir, et al. Standards Track [Page 21] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Actions of the receiver: + + The TLS server validates the certificate chain, extracts the client's + public key, and checks that the key type is appropriate for the + client authentication method. + +5.7. Client Key Exchange + + When this message is sent: + + This message is sent in all key exchange algorithms. It contains the + client's ephemeral ECDH public key. + + Meaning of the message: + + This message is used to convey ephemeral data relating to the key + exchange belonging to the client (such as its ephemeral ECDH public + key). + + Structure of this message: + + The TLS ClientKeyExchange message is extended as follows. + + enum { + implicit, + explicit + } PublicValueEncoding; + + o implicit, explicit: For ECC cipher suites, this indicates whether + the client's ECDH public key is in the client's certificate + ("implicit") or is provided, as an ephemeral ECDH public key, in + the ClientKeyExchange message ("explicit"). The implicit encoding + is deprecated and is retained here for backward compatibility + only. + + struct { + ECPoint ecdh_Yc; + } ClientECDiffieHellmanPublic; + + ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte + string ECPoint.point, which may represent an elliptic curve point in + uncompressed format. + + struct { + select (KeyExchangeAlgorithm) { + case ec_diffie_hellman: ClientECDiffieHellmanPublic; + } exchange_keys; + } ClientKeyExchange; + + + +Nir, et al. Standards Track [Page 22] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Actions of the sender: + + The client selects an ephemeral ECDH public key corresponding to the + parameters it received from the server. The format is the same as in + Section 5.4. + + Actions of the receiver: + + The server retrieves the client's ephemeral ECDH public key from the + ClientKeyExchange message and checks that it is on the same elliptic + curve as the server's ECDH key. + +5.8. Certificate Verify + + When this message is sent: + + This message is sent when the client sends a client certificate + containing a public key usable for digital signatures. + + Meaning of the message: + + This message contains a signature that proves possession of the + private key corresponding to the public key in the client's + Certificate message. + + Structure of this message: + + The TLS CertificateVerify message and the underlying signature type + are defined in the TLS base specifications, and the latter is + extended here in Section 5.4. For the "ecdsa" and "eddsa" cases, the + signature field in the CertificateVerify message contains an ECDSA or + EdDSA (respectively) signature computed over handshake messages + exchanged so far, exactly similar to CertificateVerify with other + signing algorithms: + + CertificateVerify.signature.sha_hash + SHA(handshake_messages); + CertificateVerify.signature.rawdata + handshake_messages; + + ECDSA signatures are computed as described in Section 5.10, and SHA + in the above template for sha_hash accordingly may denote a hash + algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature + consists of a pair of integers, r and s. The digitally-signed + element is encoded as an opaque vector <0..2^16-1>, the contents of + which are the DER encoding [X.690] corresponding to the following + ASN.1 notation [X.680]. + + + + +Nir, et al. Standards Track [Page 23] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Ecdsa-Sig-Value ::= SEQUENCE { + r INTEGER, + s INTEGER + } + + EdDSA signatures are generated and verified according to [RFC8032]. + The digitally-signed element is encoded as an opaque vector + <0..2^16-1>, the contents of which include the octet string output of + the EdDSA signing algorithm. + + Actions of the sender: + + The client computes its signature over all handshake messages sent or + received starting at client hello and up to but not including this + message. It uses the private key corresponding to its certified + public key to compute the signature, which is conveyed in the format + defined above. + + Actions of the receiver: + + The server extracts the client's signature from the CertificateVerify + message and verifies the signature using the public key it received + in the client's Certificate message. + +5.9. Elliptic Curve Certificates + + X.509 certificates containing ECC public keys or signed using ECDSA + MUST comply with [RFC3279] or another RFC that replaces or extends + it. X.509 certificates containing ECC public keys or signed using + EdDSA MUST comply with [RFC8410]. Clients SHOULD use the elliptic + curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and + SEC 2 [SECG-SEC2], or in [RFC8032]. + + EdDSA keys using the Ed25519 algorithm MUST use the ed25519 signature + algorithm, and Ed448 keys MUST use the ed448 signature algorithm. + This document does not define use of Ed25519ph and Ed448ph keys with + TLS. Ed25519, Ed25519ph, Ed448, and Ed448ph keys MUST NOT be used + with ECDSA. + +5.10. ECDH, ECDSA, and RSA Computations + + All ECDH calculations for the NIST curves (including parameter and + key generation as well as the shared secret calculation) are + performed according to [IEEE.P1363] using the ECKAS-DH1 scheme with + the identity map as the Key Derivation Function (KDF) so that the + premaster secret is the x-coordinate of the ECDH shared secret + elliptic curve point represented as an octet string. Note that this + octet string (Z in IEEE 1363 terminology), as output by FE2OSP (Field + + + +Nir, et al. Standards Track [Page 24] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + Element to Octet String Conversion Primitive), has constant length + for any given field; leading zeros found in this octet string MUST + NOT be truncated. + + (Note that this use of the identity KDF is a technicality. The + complete picture is that ECDH is employed with a non-trivial KDF + because TLS does not directly use the premaster secret for anything + other than for computing the master secret. In TLS 1.0 and 1.1, this + means that the MD5- and SHA-1-based TLS Pseudorandom Function (PRF) + serves as a KDF; in TLS 1.2, the KDF is determined by ciphersuite, + and it is conceivable that future TLS versions or new TLS extensions + introduced in the future may vary this computation.) + + An ECDHE key exchange using X25519 (curve x25519) goes as follows: + (1) each party picks a secret key d uniformly at random and computes + the corresponding public key x = X25519(d, G); (2) parties exchange + their public keys and compute a shared secret as x_S = X25519(d, + x_peer); and (3), if either party obtains all-zeroes x_S, it MUST + abort the handshake (as required by definition of X25519 and X448). + ECDHE for X448 works similarly, replacing X25519 with X448 and x25519 + with x448. The derived shared secret is used directly as the + premaster secret, which is always exactly 32 bytes when ECDHE with + X25519 is used and 56 bytes when ECDHE with X448 is used. + + All ECDSA computations MUST be performed according to ANSI X9.62 or + its successors. Data to be signed/verified is hashed, and the result + runs directly through the ECDSA algorithm with no additional hashing. + A secure hash function such as SHA-256, SHA-384, or SHA-512 from + [FIPS.180-4] MUST be used. + + All EdDSA computations MUST be performed according to [RFC8032] or + its successors. Data to be signed/verified is run through the EdDSA + algorithm with no hashing (EdDSA will internally run the data through + the "prehash" function PH). The context parameter for Ed448 MUST be + set to the empty string. + + RFC 4492 anticipated the standardization of a mechanism for + specifying the required hash function in the certificate, perhaps in + the parameters field of the subjectPublicKeyInfo. Such + standardization never took place, and as a result, SHA-1 is used in + TLS 1.1 and earlier (except for EdDSA, which uses identity function). + TLS 1.2 added a SignatureAndHashAlgorithm parameter to the + DigitallySigned struct, thus allowing agility in choosing the + signature hash. EdDSA signatures MUST have HashAlgorithm of 8 + (Intrinsic). + + All RSA signatures must be generated and verified according to + Section 7.2 of [RFC8017]. + + + +Nir, et al. Standards Track [Page 25] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +5.11. Public Key Validation + + With the NIST curves, each party MUST validate the public key sent by + its peer in the ClientKeyExchange and ServerKeyExchange messages. A + receiving party MUST check that the x and y parameters from the + peer's public value satisfy the curve equation, y^2 = x^3 + ax + b + mod p. See Section 2.3 of [Menezes] for details. Failing to do so + allows attackers to gain information about the private key to the + point that they may recover the entire private key in a few requests + if that key is not really ephemeral. + + With X25519 and X448, a receiving party MUST check whether the + computed premaster secret is the all-zero value and abort the + handshake if so, as described in Section 6 of [RFC7748]. + + Ed25519 and Ed448 internally do public key validation as part of + signature verification. + +6. Cipher Suites + + The table below defines ECC cipher suites that use the key exchange + algorithms specified in Section 2. + + +-----------------------------------------+----------------+ + | CipherSuite | Identifier | + +-----------------------------------------+----------------+ + | TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } | + | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } | + | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } | + | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } | + | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } | + | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } | + | | | + | TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } | + | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } | + | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } | + | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } | + | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2F } | + | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x30 } | + | | | + | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } | + | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } | + | TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } | + | TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } | + +-----------------------------------------+----------------+ + + Table 3: TLS ECC Cipher Suites + + + + +Nir, et al. Standards Track [Page 26] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + The key exchange method, cipher, and hash algorithm for each of these + cipher suites are easily determined by examining the name. Ciphers + (other than AES ciphers) and hash algorithms are defined in [RFC2246] + and [RFC4346]. AES ciphers are defined in [RFC5246], and AES-GCM + ciphersuites are in [RFC5289]. + + Server implementations SHOULD support all of the following cipher + suites, and client implementations SHOULD support at least one of + them: + + o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 + + o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA + + o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 + + o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA + +7. Implementation Status + + Both ECDHE and ECDSA with the NIST curves are widely implemented and + supported in all major browsers and all widely used TLS libraries. + ECDHE with Curve25519 is by now implemented in several browsers and + several TLS libraries including OpenSSL. Curve448 and EdDSA have + working interoperable implementations, but they are not yet as widely + deployed. + +8. Security Considerations + + Security issues are discussed throughout this memo. + + For TLS handshakes using ECC cipher suites, the security + considerations in Appendix D of each of the three TLS base documents + apply accordingly. + + Security discussions specific to ECC can be found in [IEEE.P1363] and + [ANSI.X9-62.2005]. One important issue that implementers and users + must consider is elliptic curve selection. Guidance on selecting an + appropriate elliptic curve size is given in Table 1. Security + considerations specific to X25519 and X448 are discussed in Section 7 + of [RFC7748]. + + Beyond elliptic curve size, the main issue is elliptic curve + structure. As a general principle, it is more conservative to use + elliptic curves with as little algebraic structure as possible. + Thus, random curves are more conservative than special curves such as + Koblitz curves, and curves over F_p with p random are more + conservative than curves over F_p with p of a special form, and + + + +Nir, et al. Standards Track [Page 27] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + curves over F_p with p random are considered more conservative than + curves over F_2^m as there is no choice between multiple fields of + similar size for characteristic 2. + + Another issue is the potential for catastrophic failures when a + single elliptic curve is widely used. In this case, an attack on the + elliptic curve might result in the compromise of a large number of + keys. Again, this concern may need to be balanced against efficiency + and interoperability improvements associated with widely used curves. + Substantial additional information on elliptic curve choice can be + found in [IEEE.P1363], [ANSI.X9-62.2005], and [FIPS.186-4]. + + The Introduction of [RFC8032] lists the security, performance, and + operational advantages of EdDSA signatures over ECDSA signatures + using the NIST curves. + + All of the key exchange algorithms defined in this document provide + forward secrecy. Some of the deprecated key exchange algorithms do + not. + +9. IANA Considerations + + [RFC4492], the predecessor of this document, defined the IANA + registries for the following: + + o Supported Groups (Section 5.1) + + o EC Point Format (Section 5.1) + + o EC Curve Type (Section 5.4) + + IANA has prepended "TLS" to the names of these three registries. + + For each name space, this document defines the initial value + assignments and defines a range of 256 values (NamedCurve) or eight + values (ECPointFormat and ECCurveType) reserved for Private Use. The + policy for any additional assignments is "Specification Required". + (RFC 4492 required IETF review.) + + All existing entries in the "ExtensionType Values", "TLS + ClientCertificateType Identifiers", "TLS Cipher Suites", "TLS + Supported Groups", "TLS EC Point Format", and "TLS EC Curve Type" + registries that referred to RFC 4492 have been updated to refer to + this document. + + IANA has assigned the value 29 to x25519 and the value 30 to x448 in + the "TLS Supported Groups" registry. + + + + +Nir, et al. Standards Track [Page 28] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + IANA has assigned two values in the "TLS SignatureAlgorithm" registry + for ed25519 (7) and ed448 (8) with this document as reference. This + keeps compatibility with TLS 1.3. + + IANA has assigned one value from the "TLS HashAlgorithm" registry for + Intrinsic (8) with DTLS-OK set to true (Y) and this document as + reference. This keeps compatibility with TLS 1.3. + +10. References + +10.1. Normative References + + [ANSI.X9-62.2005] + American National Standards Institute, "Public Key + Cryptography for the Financial Services Industry: The + Elliptic Curve Digital Signature Algorithm (ECDSA)", + ANSI X9.62, November 2005. + + [FIPS.186-4] + National Institute of Standards and Technology, "Digital + Signature Standard (DSS)", FIPS PUB 186-4, + DOI 10.6028/NIST.FIPS.186-4, July 2013, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, DOI 10.17487/RFC2246, January 1999, + . + + [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and + Identifiers for the Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation List + (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April + 2002, . + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, + DOI 10.17487/RFC4346, April 2006, + . + + + + + + + +Nir, et al. Standards Track [Page 29] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- + 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, + DOI 10.17487/RFC5289, August 2008, + . + + [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves + for Security", RFC 7748, DOI 10.17487/RFC7748, January + 2016, . + + [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, + "PKCS #1: RSA Cryptography Specifications Version 2.2", + RFC 8017, DOI 10.17487/RFC8017, November 2016, + . + + [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital + Signature Algorithm (EdDSA)", RFC 8032, + DOI 10.17487/RFC8032, January 2017, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for + Ed25519, Ed448, X25519 and X448 for Use in the Internet + X.509 Public Key Infrastructure", RFC 8410, + DOI 10.17487/RFC8410, August 2018, + . + + [SECG-SEC2] + Certicom Research, "SEC 2: Recommended Elliptic Curve + Domain Parameters", Standards for Efficient Cryptography 2 + (SEC 2), Version 2.0, January 2010, + . + + [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1): + Specification of basic notation", ITU-T Recommendation + X.680, ISO/IEC 8824-1, August 2015. + + + +Nir, et al. Standards Track [Page 30] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + + [X.690] ITU-T, "Information technology-ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August + 2015. + +10.2. Informative References + + [FIPS.180-4] + National Institute of Standards and Technology, "Secure + Hash Standard (SHS)", FIPS PUB 180-4, DOI + 10.6028/NIST.FIPS.180-4, August 2015, + . + + [IEEE.P1363] + IEEE, "Standard Specifications for Public Key + Cryptography", IEEE Std P1363, + . + + [Menezes] Menezes, A. and B. Ustaoglu, "On reusing ephemeral keys in + Diffie-Hellman key agreement protocols", International + Journal of Applied Cryptography, Vol. 2, Issue 2, + DOI 10.1504/IJACT.2010.038308, January 2010. + + [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. + Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites + for Transport Layer Security (TLS)", RFC 4492, + DOI 10.17487/RFC4492, May 2006, + . + + [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman + Ephemeral Parameters for Transport Layer Security (TLS)", + RFC 7919, DOI 10.17487/RFC7919, August 2016, + . + + [TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", Work in Progress, draft-ietf-tls-tls13-28, + March 2018. + + + + + + + + + + + + +Nir, et al. Standards Track [Page 31] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +Appendix A. Equivalent Curves (Informative) + + All of the NIST curves [FIPS.186-4] and several of the ANSI curves + [ANSI.X9-62.2005] are equivalent to curves listed in Section 5.1.1. + The following table displays the curve names chosen by different + standards organizations; multiple names in one row represent aliases + for the same curve. + + +-----------+------------+------------+ + | SECG | ANSI X9.62 | NIST | + +-----------+------------+------------+ + | sect163k1 | | NIST K-163 | + | sect163r1 | | | + | sect163r2 | | NIST B-163 | + | sect193r1 | | | + | sect193r2 | | | + | sect233k1 | | NIST K-233 | + | sect233r1 | | NIST B-233 | + | sect239k1 | | | + | sect283k1 | | NIST K-283 | + | sect283r1 | | NIST B-283 | + | sect409k1 | | NIST K-409 | + | sect409r1 | | NIST B-409 | + | sect571k1 | | NIST K-571 | + | sect571r1 | | NIST B-571 | + | secp160k1 | | | + | secp160r1 | | | + | secp160r2 | | | + | secp192k1 | | | + | secp192r1 | prime192v1 | NIST P-192 | + | secp224k1 | | | + | secp224r1 | | NIST P-224 | + | secp256k1 | | | + | secp256r1 | prime256v1 | NIST P-256 | + | secp384r1 | | NIST P-384 | + | secp521r1 | | NIST P-521 | + +-----------+------------+------------+ + + Table 4: Equivalent Curves Defined by SECG, ANSI, and NIST + + + + + + + + + + + + +Nir, et al. Standards Track [Page 32] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +Appendix B. Differences from RFC 4492 + + o Renamed EllipticCurveList to NamedCurveList. + + o Added TLS 1.2. + + o Merged errata. + + o Removed the ECDH key exchange algorithms: ECDH_RSA and ECDH_ECDSA + + o Deprecated a bunch of ciphersuites: + + TLS_ECDH_ECDSA_WITH_NULL_SHA + + TLS_ECDH_ECDSA_WITH_RC4_128_SHA + + TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA + + TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA + + TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA + + TLS_ECDH_RSA_WITH_NULL_SHA + + TLS_ECDH_RSA_WITH_RC4_128_SHA + + TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA + + TLS_ECDH_RSA_WITH_AES_128_CBC_SHA + + TLS_ECDH_RSA_WITH_AES_256_CBC_SHA + + All the other RC4 ciphersuites + + o Removed unused curves and all but the uncompressed point format. + + o Added X25519 and X448. + + o Deprecated explicit curves. + + o Removed restriction on signature algorithm in certificate. + + + + + + + + + + +Nir, et al. Standards Track [Page 33] + +RFC 8422 ECC Cipher Suites for TLS August 2018 + + +Acknowledgements + + Most of the text in this document is taken from [RFC4492], the + predecessor of this document. The authors of that document were: + + o Simon Blake-Wilson + o Nelson Bolyard + o Vipul Gupta + o Chris Hawk + o Bodo Moeller + + In the predecessor document, the authors acknowledged the + contributions of Bill Anderson and Tim Dierks. + + The authors would like to thank Nikos Mavrogiannopoulos, Martin + Thomson, and Tanja Lange for contributions to this document. + +Authors' Addresses + + Yoav Nir + Check Point Software Technologies Ltd. + 5 Hasolelim st. + Tel Aviv 6789735 + Israel + + Email: ynir.ietf@gmail.com + + + Simon Josefsson + SJD AB + + Email: simon@josefsson.org + + + Manuel Pegourie-Gonnard + ARM + + Email: mpg@elzevir.fr + + + + + + + + + + + + + +Nir, et al. Standards Track [Page 34] + -- cgit v1.2.3