Draft: draft-ietf-tls-rfc4492bis

Commentary: 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
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.  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.
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. 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.
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 structure
MUST NOT be used with Ed25519 and Ed448 public keys.
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 X25519 and X448 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 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
now includes all values of NamedCurve except Ed25519(TBD3) and
Ed448(TBD4).
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 values of NamedCurve except eddsa_ed25519(TBD3) and
eddsa_ed448(TBD4).
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").  (This is "explicit" in
ECC cipher suites except when the client uses the ECDSA_fixed_ECDH
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
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.
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").  (This is "explicit" in
ECC cipher suites except when the client uses the ECDSA_fixed_ECDH
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
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.
EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the
Ed25519 curve, and Ed448 and Ed448ph keys MUST use the Ed448 curve.
Curves Curve25519, Curve448, Ed25519 and Ed448 MUST NOT be used for
ECDSA.
EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the
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.
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.
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.
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).
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 (for Ed448, any bit can be
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.
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).
Let's define legitimate values of x as the values that can be
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).
Since there are some implementation of the X25519 function that
impose this restriction on their input and others that don't,
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
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.
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 X25519.
IANA is requested to assign four values from the NamedCurve registry
with names Curve25519(TBD1), Curve448(TBD2), Ed25519(TBD3) and
Ed448(TBD4) with this document as reference.
IANA is requested to assign four values from the NamedCurve registry
with names ecdh_x25519(TBD1), ecdh_x448(TBD2), eddsa_ed25519(TBD3)
and eddsa_ed448(TBD4) with this document as reference.