Draft: draft-ietf-tls-rfc4492bis

Commentary: Changed EdDSA from being simply another two curves for ECDSA to being two different signature algorithm . Also an " Intrinsic " dummy hash algorithm for the signature_algorithms extension . Also removed some ECDH ( non - ephemeral ) cruft Also removed the adjective " new " for describing things that have been defined in TLS for over 10 years .
This document describes key exchange algorithms based on Elliptic
Curve Cryptography (ECC) for the Transport Layer Security (TLS)
protocol.  In particular, it specifies the use of Ephemeral Elliptic
Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
Digital Signature Algorithm (EdDSA) as new authentication mechanisms.
This document describes key exchange algorithms based on Elliptic
Curve Cryptography (ECC) for the Transport Layer Security (TLS)
protocol.  In particular, it specifies the use of Ephemeral Elliptic
Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
Digital Signature Algorithm (EdDSA) as authentication mechanisms.
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.  Implementations of this
algorithm SHOULD provide authentication by other means.
Note that there is no structural difference between ECDH and ECDSA
keys.  A certificate issuer may use X.509 v3 keyUsage and
extendedKeyUsage extensions to restrict the use of an ECC public key
to certain computations.  This document refers to an ECC key as ECDH-
capable if its use in ECDH is permitted.  ECDSA-capable and EdDSA-
capable are defined similarly.
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.
Note that client certificates with EdDSA public keys use this
mechanism.
The general structure of TLS extensions is described in RFC4366, and
this specification adds two new types to ExtensionType.
Indicates the set of elliptic curves supported by the client.  For
this extension, the opaque extension_data field contains
EllipticCurveList.  See supp_ec_ext for details.
Indicates the set of point formats that the client can parse.  For
this extension, the opaque extension_data field contains
ECPointFormatList.  See supp_pf_ext for details.
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 supp_ec_ext 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 supp_pf_ext for details.
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. eddsa_ed25519 and
eddsa_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.  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 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.
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, compressed, or hybrid format, but this specification
deprecates all but the uncompressed format.  For the NIST curves, the
format is repeated in UncompressedFormat for convenience.  For the
X25519 and X448 curves, the only valid representation is the one
specified in RFC7748 - 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 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 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).
Specifies the elliptic curve domain parameters associated with the
ECDH public key.
The ephemeral ECDH public key.
Indicates the ServerKeyExchange message contains an ECDH public
key.
Specifies the ECDH public key and associated domain parameters.
A hash of the params, with the signature appropriate to that hash
applied.  The private key corresponding to the certified public
key in the server's Certificate message is used for signing.
point: 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, compressed, or hybrid format, but this
specification deprecates all but the uncompressed format.  For the
NIST curves, the format is repeated in UncompressedFormat for
convenience.  For the X25519 and X448 curves, the only valid
representation is the one specified in RFC7748 - 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.
curve_type: This identifies the type of the elliptic curve domain
parameters.
namedCurve: 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 of the NamedCurve values.
curve_params: Specifies the elliptic curve domain parameters
associated with the ECDH public key.
public: The ephemeral ECDH public key.
ec_diffie_hellman: Indicates the ServerKeyExchange message
contains an ECDH public key.
params: Specifies the ECDH public key and associated domain
parameters.
signed_params: A hash of the params, with the signature
appropriate to that hash applied.  The private key corresponding
to the certified public key in the server's Certificate message is
used for signing.
Indicates that the server would like to use the corresponding
client authentication method specified in clientauth.
ecdsa_sign, etc.: Indicates that the server would like to use the
corresponding client authentication method specified in
clientauth.
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.
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.
IANA is requested to assign two values from the NamedCurve registry
with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this
document as reference.  IANA has already assigned the value 29 to
ecdh_x25519, and the value 30 to ecdh_x448.
IANA is requested to assign one value from SignatureAlgorithm
Registry with name eddsa(TBD5) with this document as reference.
IANA has already assigned the value 29 to ecdh_x25519, and the value
30 to ecdh_x448.
IANA is requested to assign two values from the NamedCurve registry
with names ed25519(TBD3) and ed448(TBD4) with this document as
reference.  To keep compatibility with TLS 1.3, TBD3 should be 0x07,
and TBD4 should be 0x08.
IANA is requested to assign one value from the "TLS HashAlgorithm
Registry" with name Intrinsic(TBD5) and this document as reference.
To keep compatibility with TLS 1.3, TBD5 should be 0x08.