Original text:
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier <del> draft-ietf-tls-rfc4492bis-03 </del>  Abstract 1. <del> Elliptic Curve Cryptography (ECC) is emerging as an attractive </del>  public-key cryptosystem, in particular for mobile (i.e., wireless) environments.  Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.  This is 2.3.  In ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent. supported by the client (cf. server_cert and ske). NOTE: A server participating in an ECDHE-ECDSA key exchange may use <del> different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyExchange message.  The server must consider the extensions in both cases. </del>  If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension, use in TLS.  Only three have seen any use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02. <del> This leaves only the following: </del>  Note that other specification have since added other values to this enumeration. secp256r1, etc: Indicates support of the corresponding named curve or <del> class of explicitly defined curves.  The named curves defined here are those specified in SEC 2 SECG-SEC2.  Note that many of these </del>  curves are also recommended in ANSI X9.62 ANSI.X9-62.2005 and FIPS <del> 186-4 FIPS.186-4.  Values 0xFE00 through 0xFEFF are reserved for private use. </del>  The NamedCurve name space is maintained by IANA.  See iana for information on how new value assignments are added. (and the corresponding elliptic curve domain parameters) to the client.  Structure of this message: <del> Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a prime field. Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a characteristic-2 field. Indicates that a named curve is used.  This option SHOULD be used when applicable. </del>  Values 248 through 255 are reserved for private use. The ECCurveType name space is maintained by IANA.  See iana for information on how new value assignments are added. <del> These parameters specify the coefficients of the elliptic curve. Each value contains the byte string representation of a field element following the conversion routine in Section 4.3.3 of ANSI.X9-62.2005. 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 or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this extension was used. Indicates representation of a characteristic-2 field using a trinomial basis. Indicates representation of a characteristic-2 field using a pentanomial basis. This identifies the type of the elliptic curve domain parameters. This is the odd prime defining the field Fp. Specifies the coefficients a and b of the elliptic curve E. Specifies the base point G on the elliptic curve. Specifies the order n of the base point. Specifies the cofactor h = #E(Fq)/n, where #E(Fq) represents the number of points on the elliptic curve E defined over the field Fq (either Fp or F2^m). This is the degree of the characteristic-2 field F2^m. The exponent k for the trinomial basis representation x^m + x^k+1. The exponents for the pentanomial representation x^m + x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). Specifies a recommended set of elliptic curve domain parameters. All those values of NamedCurve are allowed that refer to a specific curve.  Values of NamedCurve that indicate support for a class of explicitly defined curves are not allowed here (they are only permissible in the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02). Specifies the elliptic curve domain parameters associated with the ECDH public key. The ephemeral ECDH public key. </del>  The ServerKeyExchange message is extended as follows. 5.10. <del> All ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to IEEE.P1363.1998 using the ECKAS-DH1 scheme with the identity map as 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, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. </del>  (Note that this use of the identity KDF is a technicality.  The complete picture is that ECDH is employed with a non-trivial KDF future TLS versions or new TLS extensions introduced in the future may vary this computation.)  All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. All RSA signatures must be generated and verified according to PKCS1 block type 1.  6. The table below defines new ECC cipher suites that use the key 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.  Any <del> additional assignments require IETF Consensus action. </del>  9.

Reviewer comments:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519

Revised text:
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier  <ins> draft-ietf-tls-rfc4492bis-04 </ins> Abstract 1.  <ins> Elliptic Curve Cryptography (ECC) has emerged as an attractive </ins> public-key cryptosystem, in particular for mobile (i.e., wireless) environments.  Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.  This is 2.3. <ins> 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.  TBD: Do we want to rename this so that it makes sense? </ins> In ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent. supported by the client (cf. server_cert and ske). NOTE: A server participating in an ECDHE-ECDSA key exchange may use  <ins> different curves for the ECDSA key in its certificate, and for the ephemeral ECDH key in the ServerKeyExchange message.  The server MUST consider the extensions in both cases. </ins> If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension, use in TLS.  Only three have seen any use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02.  <ins> It also adds the new curves defined in CFRG-Curves.  The end result is as follows: </ins> Note that other specification have since added other values to this enumeration. secp256r1, etc: Indicates support of the corresponding named curve or  <ins> class of explicitly defined curves.  The named curves secp256r1, secp384r1, and secp521r1 are specified in SEC 2 SECG-SEC2.  These </ins> curves are also recommended in ANSI X9.62 ANSI.X9-62.2005 and FIPS  <ins> 186-4 FIPS.186-4.  Curve25519 and Curve448 are defined in CFRG- Curves.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> The NamedCurve name space is maintained by IANA.  See iana for information on how new value assignments are added. (and the corresponding elliptic curve domain parameters) to the client. <ins> The ECCCurveType enum used to have values for explicit prime and for explicit char2 curves.  Those values are now deprecated, so only one value remains: </ins> Structure of this message:  <ins> The value named_curve indicates that a named curve is used.  This option SHOULD be used when applicable. </ins> Values 248 through 255 are reserved for private use. The ECCurveType name space is maintained by IANA.  See iana for information on how new value assignments are added.  <ins> 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. 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 or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this extension was used.  For the Curve25519 and Curve448 curves, the only valid representation is the one specified in CFRG-Curves - a 32- or 56-octet representation of the u value of the point. This identifies the type of the elliptic curve domain parameters. Specifies a recommended set of elliptic curve domain parameters.  All those values of NamedCurve are allowed that refer to a specific curve.  Values of NamedCurve that indicate support for a class of explicitly defined curves are not allowed here (they are only permissible in the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02). Specifies the elliptic curve domain parameters associated with the ECDH public key. The ephemeral ECDH public key. </ins> The ServerKeyExchange message is extended as follows. 5.10.  <ins> 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.1998 using the ECKAS-DH1 scheme with the identity map as 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, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. </ins> (Note that this use of the identity KDF is a technicality.  The complete picture is that ECDH is employed with a non-trivial KDF future TLS versions or new TLS extensions introduced in the future may vary this computation.) <ins> An ECDHE key exchange using Curve25519 goes as follows.  Each party picks a secret key d uniformly at random and computes the corresponding public key x = Curve25519(d, G).  Parties exchange their public keys and compute a shared secret as x_S = Curve25519(d, x_peer).  ECDHE for Curve448 works similarily, replacing Curve25519 with Curve448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with Curve25519 is used and 56 bytes when ECDHE with Curve448 is used. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. All RSA signatures must be generated and verified according to PKCS1 block type 1. <ins> 5.11. With the NIST curves, each party must validate the public key sent by its peer before performing cryptographic computations with it. 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. Curve25519 was designed in a way that the result of Curve25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x. Let's define legitimate values of x as the values that can be obtained as x = Curve25519(G, d') for some d, and call the other values illegitimate.  The definition of the Curve25519 function shows that legitimate values all share the following property: the high- order bit of the last byte is not set. Since there are some implementation of the Curve25519 function that impose this restriction on their input and others that don't, implementations of Curve25519 in TLS SHOULD reject public keys when the high-order bit of the last byte is set (in other words, when the value of the leftmost byte is greater than 0x7F) in order to prevent implementation fingerprinting. Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with Curve25519. </ins> 6. The table below defines new ECC cipher suites that use the key 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.  Any  <ins> additional assignments require IETF Review. NOTE: IANA, please update the registries to reflect the new policy name. NOTE: RFC editor please delete these two notes prior to publication. IANA, please update these two registries to refer to this document. IANA is requested to assign two values from the NamedCurve registry with names Curve25519(TBD1) and Curve448(TBD2) with this document as reference. </ins> 9.