Original text:
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 <del> 186-4 FIPS.186-4.  Curve25519 and Curve448 are defined in CFRG- Curves.  Ed25519 and Ed448 are signature-only curves defined in CFRG- EdDSA.  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. 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 <del> extension was used.  For the Curve25519 and Curve448 curves, the only valid representation is the one specified in CFRG-Curves - a 32- or </del>  56-octet representation of the u value of the point.  This structure MUST NOT be used with Ed25519 and Ed448 public keys. 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 <del> now includes all values of NamedCurve except Ed25519(TBD3) and Ed448(TBD4). </del>  Specifies the elliptic curve domain parameters associated with the ECDH public key. or RSA_fixed_ECDH client authentication mechanism.) Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point in <del> uncompressed or compressed format.  Curves Ed25519 and Ed448 MUST NOT be used.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </del>  Actions of the sender: SECG-SEC2 or in CFRG-EdDSA. EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the <del> Ed25519 curve, and Ed448 and Ed448ph keys MUST use the Ed448 curve. Curves Curve25519, Curve448, Ed25519 and Ed448 MUST NOT be used for ECDSA. </del>  5.10. future TLS versions or new TLS extensions introduced in the future may vary this computation.) <del> 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. </del>  All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result private key, to the point that they may recover the entire private key in a few requests, if that key is not really ephemeral. <del> 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 (the same holds true for Curve448). </del>  Let's define legitimate values of x as the values that can be <del> 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 (for Ed448, any bit can be set). </del>  <del> Since there are some implementation of the Curve25519 function that </del>  impose this restriction on their input and others that don't, <del> 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 </del>  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 <del> necessary for security with Curve25519. </del>  6. IANA, please update these two registries to refer to this document. IANA is requested to assign four values from the NamedCurve registry <del> with names Curve25519(TBD1), Curve448(TBD2), Ed25519(TBD3) and Ed448(TBD4) with this document as reference. </del>  IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.

Reviewer comments:
Replace uses of Curve25519 with X25519 (and similarly with 448-bit one). Also add zero checks as required by CFRG-CURVES. Because of problems with TLS 1.2 key exchange, omitting these checks leads to security issues.
Renamed the curves to be consistent with what got merged into TLS 1.3 spec

Revised text:
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  <ins> 186-4 FIPS.186-4. ecdh_x25519 and ecdh_x448 are defined in CFRG- Curves. eddsa_ed25519 and eddsa_ed448 are signature-only curves defined in CFRG-EdDSA.  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. 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  <ins> extension was used.  For the X25519 and X448 curves, the only valid representation is the one specified in CFRG-Curves - a 32- or </ins> 56-octet representation of the u value of the point.  This structure MUST NOT be used with Ed25519 and Ed448 public keys. 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  <ins> now includes all values of NamedCurve except eddsa_ed25519(TBD3) and eddsa_ed448(TBD4). </ins> Specifies the elliptic curve domain parameters associated with the ECDH public key. or RSA_fixed_ECDH client authentication mechanism.) Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point in  <ins> uncompressed or compressed format.  Curves eddsa_ed25519 and eddsa_ed448 MUST NOT be used here.  Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used. </ins> Actions of the sender: SECG-SEC2 or in CFRG-EdDSA. EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the  <ins> eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the eddsa_ed448 curve.  Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and eddsa_ed448 MUST NOT be used for ECDSA. </ins> 5.10. future TLS versions or new TLS extensions introduced in the future may vary this computation.)  <ins> An ECDHE key exchange using X25519 (curve ecdh_x25519) goes as follows: Each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G).  Parties exchange their public keys, and compute a shared secret as x_S = X25519(d, x_peer).  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 similarily, replacing X25519 with X448, and ecdh_x25519 with ecdh_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. </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 private key, to the point that they may recover the entire private key in a few requests, if that key is not really ephemeral.  <ins> X25519 was designed in a way that the result of X25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x (the same holds true for X448). All-zeroes output from X25519 or X448 MUST NOT be used for premaster secret (as required by definition of X25519 and X448).  If the premaster secret would be all zeroes, the handshake MUST be aborted (most probably by sending a fatal alert). </ins> Let's define legitimate values of x as the values that can be  <ins> obtained as x = X25519(G, d') for some d', and call the other values illegitimate.  The definition of the X25519 function shows that legitimate values all share the following property: the high-order bit of the last byte is not set (for X448, any bit can be set). </ins>  <ins> Since there are some implementation of the X25519 function that </ins> impose this restriction on their input and others that don't,  <ins> implementations of X25519 in TLS SHOULD reject public keys when the high-order bit of the last byte is set (in other words, when the </ins> 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  <ins> necessary for security with X25519. </ins> 6. IANA, please update these two registries to refer to this document. IANA is requested to assign four values from the NamedCurve registry  <ins> with names ecdh_x25519(TBD1), ecdh_x448(TBD2), eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this document as reference. </ins> IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this document as reference.