Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8422

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier

Pages: 34
Proposed Standard
Errata
Obsoletes:  4492
Updated by:  8996
Part 3 of 3 – Pages 26 to 34
First   Prev   None

Top   ToC   RFC8422 - Page 26   prevText

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
Top   ToC   RFC8422 - Page 27
   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
Top   ToC   RFC8422 - Page 28
   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.
Top   ToC   RFC8422 - Page 29
   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>.
Top   ToC   RFC8422 - Page 30
   [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.
Top   ToC   RFC8422 - Page 31
   [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.
Top   ToC   RFC8422 - Page 32

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
Top   ToC   RFC8422 - Page 33

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.
Top   ToC   RFC8422 - Page 34

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