Draft: draft-ietf-tls-rfc4492bis

Commentary: Added new curves and new authors . Partial merge of draft - ietf - tls - curve25519
Elliptic Curve Cryptography (ECC) is emerging as an attractive
public-key cryptosystem, in particular for mobile (i.e., wireless)
environments.  Compared to currently prevalent cryptosystems such as
RSA, ECC offers equivalent security with smaller key sizes.  This is
illustrated in the following table, based on Lenstra_Verheul, which
gives approximate comparable key sizes for symmetric- and asymmetric-
key cryptosystems based on the best-known algorithms for attacking
them.
Elliptic Curve Cryptography (ECC) has emerged as an attractive
public-key cryptosystem, in particular for mobile (i.e., wireless)
environments.  Compared to currently prevalent cryptosystems such as
RSA, ECC offers equivalent security with smaller key sizes.  This is
illustrated in the following table, based on Lenstra_Verheul, which
gives approximate comparable key sizes for symmetric- and asymmetric-
key cryptosystems based on the best-known algorithms for attacking
them.
NOTE: Despite the name beginning with "ECDH_" (no E), the key used in
ECDH_anon is ephemeral just like the key in ECDHE_RSA and
ECDHE_ECDSA.  The naming follows the example of DH_anon, where the
key is also ephemeral but the name does not reflect it.  TBD: Do we
want to rename this so that it makes sense?
NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA key in its certificate, and (ii)
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 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 defined here
are those specified in SEC 2 SECG-SEC2.  Note that many of these
curves are also recommended in ANSI X9.62 ANSI.X9-62.2005 and FIPS
186-4 FIPS.186-4.  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.  Values 0xFE00 through 0xFEFF are reserved for private use.
Indicates the elliptic curve domain parameters are conveyed
verbosely, and the underlying finite field is a prime field.
Indicates the elliptic curve domain parameters are conveyed
verbosely, and the underlying finite field is a characteristic-2
field.
Indicates that a named curve is used.  This option SHOULD be used
when applicable.
These parameters specify the coefficients of the elliptic curve.
Each value contains the byte string representation of a field
element following the conversion routine in Section 4.3.3 of
ANSI.X9-62.2005.
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.
Indicates representation of a characteristic-2 field using a
trinomial basis.
Indicates representation of a characteristic-2 field using a
pentanomial basis.
This identifies the type of the elliptic curve domain parameters.
This is the odd prime defining the field Fp.
Specifies the coefficients a and b of the elliptic curve E.
Specifies the base point G on the elliptic curve.
Specifies the order n of the base point.
Specifies the cofactor h = #E(Fq)/n, where #E(Fq) represents the
number of points on the elliptic curve E defined over the field Fq
(either Fp or F2^m).
This is the degree of the characteristic-2 field F2^m.
The exponent k for the trinomial basis representation x^m + x^k+1.
The exponents for the pentanomial representation x^m + x^k3 + x^k2
+ x^k1 + 1 (such that k3 > k2 > k1).
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).
Specifies the elliptic curve domain parameters associated with the
ECDH public key.
The ephemeral ECDH public key.
The value named_curve indicates that a named curve is used.  This
option SHOULD be used when applicable.
RFC 4492 had a specification for an ECCurve structure and an
ECBasisType structure.  Both of these are omitted now because they
were only used with the now deprecated explicit curves.
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 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 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).
Specifies the elliptic curve domain parameters associated with the
ECDH public key.
The ephemeral ECDH public key.
All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) are performed according to
IEEE.P1363.1998 using the ECKAS-DH1 scheme with the identity map as
key derivation function (KDF), so that the premaster secret is the
x-coordinate of the ECDH shared secret elliptic curve point
represented as an octet string.  Note that this octet string (Z in
IEEE 1363 terminology) as output by FE2OSP, the Field Element to
Octet String Conversion Primitive, has constant length for any given
field; leading zeros found in this octet string MUST NOT be
truncated.
All ECDH calculations for the NIST curves (including parameter and
key generation as well as the shared secret calculation) are
performed according to IEEE.P1363.1998 using the ECKAS-DH1 scheme
with the identity map as key derivation function (KDF), so that the
premaster secret is the x-coordinate of the ECDH shared secret
elliptic curve point represented as an octet string.  Note that this
octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the
Field Element to Octet String Conversion Primitive, has constant
length for any given field; leading zeros found in this octet string
MUST NOT be truncated.
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.
With the NIST curves, each party must validate the public key sent by
its peer before performing cryptographic computations with it.
Failing to do so allows attackers to gain information about the
private key, to the point that they may recover the entire private
key in a few requests, if that key is not really ephemeral.
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.
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.
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.
For each name space, this document defines the initial value
assignments and defines a range of 256 values (NamedCurve) or eight
values (ECPointFormat and ECCurveType) reserved for Private Use.  Any
additional assignments require IETF Consensus action.
For each name space, this document defines the initial value
assignments and defines a range of 256 values (NamedCurve) or eight
values (ECPointFormat and ECCurveType) reserved for Private Use.  Any
additional assignments require IETF Review.
NOTE: IANA, please update the registries to reflect the new policy
name.
NOTE: RFC editor please delete these two notes prior to publication.
IANA, please update these two registries to refer to this document.
IANA is requested to assign two values from the NamedCurve registry
with names Curve25519(TBD1) and Curve448(TBD2) with this document as
reference.