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.

       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.

Both client and server perform an ECDH operation 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 that 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.

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.

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 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 should be sent as described in Section 2, and the CertificateVerify should 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 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.

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 and compression techniques 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.

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:

   enum {
       elliptic_curves(10),
       ec_point_formats(11)
   } ExtensionType;

The general structure of TLS extensions is described in [RFC4366], and this specification adds two types to ExtensionType.

• 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 EllipticCurveList. See Section 5.1.1 for details.
• 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.

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. Section 5.3 and Section 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 "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 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),
            ecdh_x25519(29), ecdh_x448(30),
            reserved (0xFE00..0xFEFF),
            deprecated(0xFF01..0xFF02),
            (0xFFFF)
        } NamedCurve;

Note that other specifications have since added other values to this enumeration.

secp256r1, etc: Indicates support of the corresponding named curve or class of explicitly defined curves. 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 ecdh_x25519 and ecdh_x448 are defined in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for private use.

The NamedCurve name space is maintained by IANA. See Section 8 for information on how new value assignments are added.

        struct {
            NamedCurve elliptic_curve_list<2..2^16-1>
        } EllipticCurveList;

Items in elliptic_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

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 MUST still be included, and contain exactly one value: the uncompressed point format (0).

The ECPointFormat name space is maintained by IANA. See Section 8 for information on how new value assignments are added.

Items in ec_point_format_list are ordered according to the client's preferences (favorite choice first).

        00 0B 00 02 01 00

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):

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 pre-hashed) forms of EdDSA do not hash the data before signing it. For this reason it does not make sense to combine them with a signature algorithm in the extension.

For bits-on-the-wire compatibility with TLS 1.3, we define a new dummy value in the HashAlgorithm registry which we will call "Intrinsic" (value TBD5) meaning that hashing is intrinsic to the signature algorithm.

To represent ed25519 and ed448 in the signature_algorithms extension, the value shall be (TBD5,TBD3) and (TBD5,TBD4) 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 (e.g., the server may prefer to receive points in compressed format even when a client cannot parse this format: the same client may nevertheless be capable of outputting points in compressed format).

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.

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. Section 5.6 and Section 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 3 apply only to the server's certificate (first in the chain).

        enum {
            deprecated (1..2),
            named_curve (3),
            reserved(248..255)
        } ECCurveType;

        struct {
            opaque point <1..2^8-1>;
        } ECPoint;

        struct {
            ECCurveType    curve_type;
            select (curve_type) {
                case named_curve:
                    NamedCurve namedcurve;
            };
        } ECParameters;

        struct {
            ECParameters    curve_params;
            ECPoint         public;
        } ServerECDHParams;

        enum {
            ec_diffie_hellman
        } KeyExchangeAlgorithm;

   select (KeyExchangeAlgorithm) {
       case ec_diffie_hellman:
           ServerECDHParams    params;
           Signature           signed_params;
   } ServerKeyExchange;

     enum {
         ecdsa(3),
         ed25519(TBD3)
         ed448(TBD4)
     } 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;

           Ecdsa-Sig-Value ::= SEQUENCE {
               r       INTEGER,
               s       INTEGER
           }

          enum {
              uncompressed(4),
              (255)
            } PointConversionForm;
            
          struct {
              PointConversionForm  form;
              opaque               X[coordinate_length];
              opaque               Y[coordinate_length];
          } UncompressedPointRepresentation;
          

        enum {
            ecdsa_sign(64),
            rsa_fixed_ecdh(65),
            ecdsa_fixed_ecdh(66),
            (255)
        } ClientCertificateType;

        enum {
            implicit,
            explicit
        } PublicValueEncoding;

        struct {
            select (PublicValueEncoding) {
                case implicit: struct { };
                case explicit: ECPoint ecdh_Yc;
            } ecdh_public;
        } ClientECDiffieHellmanPublic;

        struct {
            select (KeyExchangeAlgorithm) {
                case ec_diffie_hellman: ClientECDiffieHellmanPublic;
            } exchange_keys;
        } ClientKeyExchange;

        CertificateVerify.signature.sha_hash
            SHA(handshake_messages);
        CertificateVerify.signature.rawdata
            handshake_messages;

        Ecdsa-Sig-Value ::= SEQUENCE {
            r       INTEGER,
            s       INTEGER
        }