Draft: draft-ietf-tls-rfc4492bis

Commentary: This replaces Ilari 's pull request . For some reason I ca n't update that one .
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) as a new
authentication mechanism.
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.
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 is defined
similarly.
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.
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
capable public key and be signed with ECDSA.
The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message.  These
parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate.
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- or
EdDSA-capable public key.
The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message.  These
parameters MUST be signed with ECDSA or EdDSA using the private key
corresponding to the public key in the server's Certificate.
To use this authentication mechanism, the client MUST possess a
certificate containing an ECDSA-capable public key.
To use this authentication mechanism, the client MUST possess a
certificate containing an ECDSA- or EdDSA-capable public key.
NOTE: A server participating in an ECDHE-ECDSA key exchange may use
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.
NOTE: A server participating in an ECDHE_ECDSA key exchange may use
different curves for the ECDSA or EdDSA key in its certificate, and
for the ephemeral ECDH key in the ServerKeyExchange message.  The
server MUST consider the extensions in both cases.
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.  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.  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.
Three point formats were included in the definition of ECPointFormat
above.  This specification deprecates all but the uncompressed point
format.  Implementations of this document MUST support the
uncompressed format for all of their supported curves, and MUST
support no other formats for curves defined in this specification.
For backwards compatibility purposes, the point format list extension
MUST still be included, and contain exactly one value: the
uncomptessed point format (0).
Three point formats were included in the definition of ECPointFormat
above.  This specification deprecates all but the uncompressed point
format.  Implementations of this document MUST support the
uncompressed format for all of their supported curves, and MUST NOT
support other formats for curves defined in this specification.  For
backwards compatibility purposes, the point format list extension
MUST still be included, and contain exactly one value: the
uncomptessed point format (0).
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.
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).
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.
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).
NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
algorithm and "anonymous" for ECDH_anon.  These cases are defined in
TLS.  SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA.  ECDSA
signatures are generated and verified as described in alg_computes,
and SHA in the above template for sha_hash accordingly may denote a
hash algorithm other than SHA-1.  As per ANSI X9.62, an ECDSA
signature consists of a pair of integers, r and s.  The digitally-
signed element is encoded as an opaque vector <0..2^16-1>, the
contents of which are the DER encoding corresponding to the following
ASN.1 notation.
NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
algorithm and "anonymous" for ECDH_anon.  These cases are defined in
TLS.  SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA.
ECDSA signatures are generated and verified as described in
alg_computes, and SHA in the above template for sha_hash accordingly
may denote a hash algorithm other than SHA-1.  As per ANSI X9.62, an
ECDSA signature consists of a pair of integers, r and s.  The
digitally-signed element is encoded as an opaque vector <0..2^16-1>,
the contents of which are the DER encoding corresponding to the
following ASN.1 notation.
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.  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 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.
X.509 certificates containing ECC public keys or signed using ECDSA
MUST comply with RFC3279 or another RFC that replaces or extends it.
Clients SHOULD use the elliptic curve domain parameters recommended
in ANSI X9.62, FIPS 186-4, and SEC 2 SECG-SEC2.
X.509 certificates containing ECC public keys or signed using ECDSA
MUST comply with RFC3279 or another RFC that replaces or extends it.
X.509 certificates containing ECC public keys or signed using EdDSA
MUST comply with PKIX-EdDSA.  Clients SHOULD use the elliptic curve
domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2
SECG-SEC2 or in CFRG-EdDSA.
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.
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.
The default hash function is SHA-1 FIPS.180-2, and sha_size (see ske
and cert_verify) is 20.  However, an alternative hash function, such
as one of the new SHA hash functions specified in FIPS 180-2
FIPS.180-2, may be used instead.
RFC 4492 anticipated the standardization of a mechanism for
specifying the required hash function in the certificate, perhaps in
the parameters field of the subjectPublicKeyInfo.  Such
standardization never took place, and as a result, SHA-1 is used in
TLS 1.1 and earlier.  TLS 1.2 added a SignatureAndHashAlgorithm
parameter to the DigitallySigned struct, thus allowing agility in
choosing the signature hash.
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.
The default hash function is SHA-1 FIPS.180-2, and sha_size (see ske
and cert_verify) is 20.  However, an alternative hash function, such
as one of the new SHA hash functions specified in FIPS 180-2
FIPS.180-2, SHOULD be used instead.
All EdDSA computations MUST be performed according to CFRG-EdDSA or
its succesors.  Data to be signed/verified is run through the EdDSA
algorithm wih no hashing (EdDSA will internally run the data through
the PH function).
RFC 4492 anticipated the standardization of a mechanism for
specifying the required hash function in the certificate, perhaps in
the parameters field of the subjectPublicKeyInfo.  Such
standardization never took place, and as a result, SHA-1 is used in
TLS 1.1 and earlier (except for EdDSA, which uses identity function).
TLS 1.2 added a SignatureAndHashAlgorithm parameter to the
DigitallySigned struct, thus allowing agility in choosing the
signature hash.  EdDSA signatures MUST have HashAlgorithm of 0
(None).
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.
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).
Ed25519 and Ed448 internally do public key validation as part of
signature verification.
IANA is requested to assign two values from the NamedCurve registry
with names Curve25519(TBD1) and Curve448(TBD2) with this document as
reference.
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 one value from SignatureAlgorithm
Registry with name eddsa(TBD5) with this document as reference.
Add support for CFRG curves and signatures work.