Draft: draft-ietf-tls-rfc4492bis

Commentary: ecdhx25519 and ecdhx448 no longer have an ecdh _ prefix ( .Remove some remnants of EdDSA curves as NamedCurves . TLS 1.3 only uses the PureEdDSA algorithms . If we were to use Ed25519ph , we would want separate SignatureAlgorithm values so the receivers can indicate support . 
 ( suggested I file this here . ) In TLS 1.3 , we dropped the " ecdh " prefix on ecdhx25519 and ecdh_x448 when we split signatures from NamedCurve / Group . The documents should probably match in naming one way or another . I think plain x25519 and  is tidier . X25519 already denotes the ECDH function , as opposed to  which is the curve . 
 Looks fine to me
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 ecdh_x25519 and ecdh_x448
are defined in RFC7748.  Values 0xFE00 through 0xFEFF are reserved
for private use.
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.
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").  (This is "explicit"
in ECC cipher suites except when the client uses the
ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
mechanism.)
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 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.
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").  (This is "explicit"
in ECC cipher suites except when the client uses the
ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
mechanism.)
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 or compressed format.  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
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.
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.
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.
An ECDHE key exchange using X25519 (curve 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 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.
IANA has already assigned the value 29 to ecdh_x25519, and the value
30 to ecdh_x448.
IANA is requested to assigned the value 29 to x25519, and the value
30 to x448 in the TLS Supported Groups Registry.  This replaces the
temporary registrations ecdh_x25519(29) and ecdh_x448(30).