RFC 8422
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier
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
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_SHA7. 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
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.
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, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.186-4.pdf>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <https://www.rfc-editor.org/info/rfc2246>. [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, <https://www.rfc-editor.org/info/rfc3279>. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.
[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, <https://www.rfc-editor.org/info/rfc4366>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>. [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, <https://www.rfc-editor.org/info/rfc5289>. [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>. [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, <https://www.rfc-editor.org/info/rfc8017>. [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [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, <https://www.rfc-editor.org/info/rfc8410>. [SECG-SEC2] Certicom Research, "SEC 2: Recommended Elliptic Curve Domain Parameters", Standards for Efficient Cryptography 2 (SEC 2), Version 2.0, January 2010, <http://www.secg.org/sec2-v2.pdf>. [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.
[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, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>. [IEEE.P1363] IEEE, "Standard Specifications for Public Key Cryptography", IEEE Std P1363, <http://ieeexplore.ieee.org/document/891000/>. [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, <https://www.rfc-editor.org/info/rfc4492>. [RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, <https://www.rfc-editor.org/info/rfc7919>. [TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-28, March 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
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.
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