doc: Add RFC documents

1 files changed, 1907 insertions, 0 deletions

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,
+              <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>.
+
+
+
+
+
+
+
+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,
+              <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.
+
+
+
+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,
+              <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.
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+