< draft-ietf-tls-rfc4492bis-07.txt   draft-ietf-tls-rfc4492bis-08.txt >
TLS Working Group Y. Nir TLS Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Obsoletes: 4492 (if approved) S. Josefsson Obsoletes: 4492 (if approved) S. Josefsson
Intended status: Standards Track SJD AB Intended status: Standards Track SJD AB
Expires: September 23, 2016 M. Pegourie-Gonnard Expires: January 9, 2017 M. Pegourie-Gonnard
Independent / PolarSSL Independent / PolarSSL
March 22, 2016 July 8, 2016
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier Security (TLS) Versions 1.2 and Earlier
draft-ietf-tls-rfc4492bis-07 draft-ietf-tls-rfc4492bis-08
Abstract Abstract
This document describes key exchange algorithms based on Elliptic This document describes key exchange algorithms based on Elliptic
Curve Cryptography (ECC) for the Transport Layer Security (TLS) Curve Cryptography (ECC) for the Transport Layer Security (TLS)
protocol. In particular, it specifies the use of Ephemeral Elliptic protocol. In particular, it specifies the use of Ephemeral Elliptic
Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
Digital Signature Algorithm (EdDSA) as new authentication mechanisms. Digital Signature Algorithm (EdDSA) as new authentication mechanisms.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 23, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 4 2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 4
2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Client Authentication . . . . . . . . . . . . . . . . . . . . 7 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 7
3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7
4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 7 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 8
5. Data Structures and Computations . . . . . . . . . . . . . . 8 5. Data Structures and Computations . . . . . . . . . . . . . . 8
5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 9
5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 10 5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 10
5.1.2. Supported Point Formats Extension . . . . . . . . . . 11 5.1.2. Supported Point Formats Extension . . . . . . . . . . 11
5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 12 5.2. Server Hello Extension . . . . . . . . . . . . . . . . . 12
5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 13 5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 13
5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 14 5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 14
5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 17 5.4.1. Uncompressed Point Format for NIST curves . . . . . . 17
5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 18 5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 18
5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 19 5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 19
5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 20
5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 21 5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 21
5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 22 5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 23
5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 22 5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 23
5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 23 5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 24
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
10. Version History for This Draft . . . . . . . . . . . . . . . 27 10. Version History for This Draft . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 30 Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 30
Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 30 Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Elliptic Curve Cryptography (ECC) has emerged as an attractive Elliptic Curve Cryptography (ECC) has emerged as an attractive
public-key cryptosystem, in particular for mobile (i.e., wireless) public-key cryptosystem, in particular for mobile (i.e., wireless)
environments. Compared to currently prevalent cryptosystems such as environments. Compared to currently prevalent cryptosystems such as
RSA, ECC offers equivalent security with smaller key sizes. This is RSA, ECC offers equivalent security with smaller key sizes. This is
illustrated in the following table, based on [Lenstra_Verheul], which illustrated in the following table, based on [Lenstra_Verheul], which
gives approximate comparable key sizes for symmetric- and asymmetric- gives approximate comparable key sizes for symmetric- and asymmetric-
key cryptosystems based on the best-known algorithms for attacking key cryptosystems based on the best-known algorithms for attacking
skipping to change at page 10, line 47 skipping to change at page 11, line 9
(0xFFFF) (0xFFFF)
} NamedCurve; } NamedCurve;
Note that other specification have since added other values to this Note that other specification have since added other values to this
enumeration. enumeration.
secp256r1, etc: Indicates support of the corresponding named curve or secp256r1, etc: Indicates support of the corresponding named curve or
class of explicitly defined curves. The named curves secp256r1, class of explicitly defined curves. The named curves secp256r1,
secp384r1, and secp521r1 are specified in SEC 2 [SECG-SEC2]. These 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 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 186-4 [FIPS.186-4]. The rest of this document refers to these three
[RFC7748]. eddsa_ed25519 and eddsa_ed448 are signature-only curves curves as the "NIST curves" because they were originally standardized
defined in [CFRG-EdDSA]. Values 0xFE00 through 0xFEFF are reserved by the National Institute of Standards and Technology. The curves
for private use. 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.
The NamedCurve name space is maintained by IANA. See Section 8 for The NamedCurve name space is maintained by IANA. See Section 8 for
information on how new value assignments are added. information on how new value assignments are added.
struct { struct {
NamedCurve elliptic_curve_list<2..2^16-1> NamedCurve elliptic_curve_list<2..2^16-1>
} EllipticCurveList; } EllipticCurveList;
Items in elliptic_curve_list are ordered according to the client's Items in elliptic_curve_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
skipping to change at page 11, line 27 skipping to change at page 11, line 38
and prefers to use secp256r1 would include a TLS extension consisting and prefers to use secp256r1 would include a TLS extension consisting
of the following octets. Note that the first two octets indicate the of the following octets. Note that the first two octets indicate the
extension type (Supported Elliptic Curves Extension): extension type (Supported Elliptic Curves Extension):
00 0A 00 06 00 04 00 17 00 18 00 0A 00 06 00 04 00 17 00 18
5.1.2. Supported Point Formats Extension 5.1.2. Supported Point Formats Extension
enum { enum {
uncompressed (0), uncompressed (0),
ansiX962_compressed_prime (1), deprecated (1..2),
ansiX962_compressed_char2 (2),
reserved (248..255) reserved (248..255)
} ECPointFormat; } ECPointFormat;
struct { struct {
ECPointFormat ec_point_format_list<1..2^8-1> ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList; } ECPointFormatList;
Three point formats were included in the definition of ECPointFormat Three point formats were included in the definition of ECPointFormat
above. This specification deprecates all but the uncompressed point above. This specification deprecates all but the uncompressed point
format. Implementations of this document MUST support the format. Implementations of this document MUST support the
uncompressed format for all of their supported curves, and MUST NOT uncompressed format for all of their supported curves, and MUST NOT
skipping to change at page 15, line 12 skipping to change at page 15, line 21
ECBasisType structure. Both of these are omitted now because they ECBasisType structure. Both of these are omitted now because they
were only used with the now deprecated explicit curves. were only used with the now deprecated explicit curves.
struct { struct {
opaque point <1..2^8-1>; opaque point <1..2^8-1>;
} ECPoint; } ECPoint;
This is the byte string representation of an elliptic curve point This is the byte string representation of an elliptic curve point
following the conversion routine in Section 4.3.6 of following the conversion routine in Section 4.3.6 of
[ANSI.X9-62.2005]. This byte string may represent an elliptic curve [ANSI.X9-62.2005]. This byte string may represent an elliptic curve
point in uncompressed or compressed format; it MUST conform to what point in uncompressed, compressed, or hybrid format, but this
the client has requested through a Supported Point Formats Extension specification deprecates all but the uncompressed format. For the
if this extension was used. For the X25519 and X448 curves, the only NIST curves, the format is repeated in Section 5.4.1 for convenience.
valid representation is the one specified in [RFC7748] - a 32- or For the X25519 and X448 curves, the only valid representation is the
56-octet representation of the u value of the point. This structure one specified in [RFC7748] - a 32- or 56-octet representation of the
MUST NOT be used with Ed25519 and Ed448 public keys. u value of the point. This structure MUST NOT be used with Ed25519
and Ed448 public keys.
struct { struct {
ECCurveType curve_type; ECCurveType curve_type;
select (curve_type) { select (curve_type) {
case named_curve: case named_curve:
NamedCurve namedcurve; NamedCurve namedcurve;
}; };
} ECParameters; } ECParameters;
This identifies the type of the elliptic curve domain parameters. This identifies the type of the elliptic curve domain parameters.
skipping to change at page 16, line 42 skipping to change at page 17, line 4
ServerKeyExchange.signed_params.sha_hash ServerKeyExchange.signed_params.sha_hash
SHA(ClientHello.random + ServerHello.random + SHA(ClientHello.random + ServerHello.random +
ServerKeyExchange.params); ServerKeyExchange.params);
ServerKeyExchange.signed_params.rawdata ServerKeyExchange.signed_params.rawdata
ClientHello.random + ServerHello.random + ClientHello.random + ServerHello.random +
ServerKeyExchange.params; ServerKeyExchange.params;
NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
algorithm and "anonymous" for ECDH_anon. These cases are defined in algorithm and "anonymous" for ECDH_anon. These cases are defined in
TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA. TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA.
ECDSA signatures are generated and verified as described in ECDSA signatures are generated and verified as described in
Section 5.10, and SHA in the above template for sha_hash accordingly Section 5.10, 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 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 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>, digitally-signed element is encoded as an opaque vector <0..2^16-1>,
the contents of which are the DER encoding corresponding to the the contents of which are the DER encoding corresponding to the
following ASN.1 notation. following ASN.1 notation.
Ecdsa-Sig-Value ::= SEQUENCE { Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER, r INTEGER,
s INTEGER s INTEGER
} }
EdDSA signatures are generated and verified according to EdDSA signatures in both the protocol and in certificates that
conform to [PKIX-EdDSA] are generated and verified according to
[CFRG-EdDSA]. The digitally-signed element is encoded as an opaque [CFRG-EdDSA]. The digitally-signed element is encoded as an opaque
vector<0..2^16-1>, the contents of which is the octet string output vector<0..2^16-1>, the contents of which is the octet string output
of the EdDSA signing algorithm. of the EdDSA signing algorithm.
Actions of the sender: Actions of the sender:
The server selects elliptic curve domain parameters and an ephemeral The server selects elliptic curve domain parameters and an ephemeral
ECDH public key corresponding to these parameters according to the ECDH public key corresponding to these parameters according to the
ECKAS-DH1 scheme from IEEE 1363 [IEEE.P1363.1998]. It conveys this ECKAS-DH1 scheme from IEEE 1363 [IEEE.P1363.1998]. It conveys this
information to the client in the ServerKeyExchange message using the information to the client in the ServerKeyExchange message using the
skipping to change at page 17, line 32 skipping to change at page 17, line 41
Actions of the receiver: Actions of the receiver:
The client verifies the signature (when present) and retrieves the The client verifies the signature (when present) and retrieves the
server's elliptic curve domain parameters and ephemeral ECDH public server's elliptic curve domain parameters and ephemeral ECDH public
key from the ServerKeyExchange message. (A possible reason for a key from the ServerKeyExchange message. (A possible reason for a
fatal handshake failure is that the client's capabilities for fatal handshake failure is that the client's capabilities for
handling elliptic curves and point formats are exceeded; cf. handling elliptic curves and point formats are exceeded; cf.
Section 5.1.) Section 5.1.)
5.4.1. Uncompressed Point Format for NIST curves
The following represents the wire format for representing ECPoint in
ServerKeyExchange records. The first octet of the representation
indicates the form, which may be compressed, uncompressed, or hybrid.
This specification supports only the uncompressed format for these
curves. This is followed by the binary representation of the X value
in "big-endian" or "network" format, followed by the binary
representation of the Y value in "big-endian" or "network" format.
There are no internal length markers, so each number representation
occupies as many octets as implied by the curve parameters. For
P-256 this means that each of X and Y use 32 octets, padded on the
left by zeros if necessary. For P-384 they take 48 octets each, and
for P-521 they take 66 octets each.
Here's a more formal representation:
enum {
uncompressed(4),
(255)
} PointConversionForm;
struct {
PointConversionForm form;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
5.5. Certificate Request 5.5. Certificate Request
When this message is sent: When this message is sent:
This message is sent when requesting client authentication. This message is sent when requesting client authentication.
Meaning of this message: Meaning of this message:
The server uses this message to suggest acceptable client The server uses this message to suggest acceptable client
authentication methods. authentication methods.
skipping to change at page 23, line 45 skipping to change at page 24, line 34
DigitallySigned struct, thus allowing agility in choosing the DigitallySigned struct, thus allowing agility in choosing the
signature hash. EdDSA signatures MUST have HashAlgorithm of 0 signature hash. EdDSA signatures MUST have HashAlgorithm of 0
(None). (None).
All RSA signatures must be generated and verified according to All RSA signatures must be generated and verified according to
[PKCS1] block type 1. [PKCS1] block type 1.
5.11. Public Key Validation 5.11. Public Key Validation
With the NIST curves, each party must validate the public key sent by With the NIST curves, each party must validate the public key sent by
its peer before performing cryptographic computations with it. its peer. A receiving party MUST check that the x and y parameters
Failing to do so allows attackers to gain information about the from the peer's public value satisfy the curve equation, y^2 = x^3 +
private key, to the point that they may recover the entire private ax + b mod p. See section 2.3 of [Menezes] for details. Failing to
key in a few requests, if that key is not really ephemeral. 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.
X25519 was designed in a way that the result of X25519(x, d) will X25519 was designed in a way that the result of X25519(x, d) will
never reveal information about d, provided it was chosen as never reveal information about d, provided it was chosen as
prescribed, for any value of x (the same holds true for X448). 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 All-zeroes output from X25519 or X448 MUST NOT be used for premaster
secret (as required by definition of X25519 and X448). If the secret (as required by definition of X25519 and X448). If the
premaster secret would be all zeroes, the handshake MUST be aborted premaster secret would be all zeroes, the handshake MUST be aborted
(most probably by sending a fatal alert). (most probably by sending a fatal alert).
Let's define legitimate values of x as the values that can be 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 obtained as x = X25519(G, d') for some d', and call the other values
illegitimate. The definition of the X25519 function shows that illegitimate. The definition of the X25519 function shows that
legitimate values all share the following property: the high-order 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). 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 Since there are some implementation of the X25519 function that
impose this restriction on their input and others that don't, impose this restriction on their input and others that don't,
implementations of X25519 in TLS SHOULD reject public keys when the 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 high-order bit of the final byte is set (in other words, when the
value of the leftmost byte is greater than 0x7F) in order to prevent value of the rightmost byte is greater than 0x7F) in order to prevent
implementation fingerprinting. implementation fingerprinting. Note that this deviates from RFC 7748
which suggests that This value be masked.
Ed25519 and Ed448 internally do public key validation as part of Ed25519 and Ed448 internally do public key validation as part of
signature verification. signature verification.
Other than this recommended check, implementations do not need to Other than this recommended check, implementations do not need to
ensure that the public keys they receive are legitimate: this is not ensure that the public keys they receive are legitimate: this is not
necessary for security with X25519. necessary for security with X25519.
6. Cipher Suites 6. Cipher Suites
skipping to change at page 25, line 52 skipping to change at page 26, line 26
Security issues are discussed throughout this memo. Security issues are discussed throughout this memo.
For TLS handshakes using ECC cipher suites, the security For TLS handshakes using ECC cipher suites, the security
considerations in appendices D of all three TLS base documemts apply considerations in appendices D of all three TLS base documemts apply
accordingly. accordingly.
Security discussions specific to ECC can be found in Security discussions specific to ECC can be found in
[IEEE.P1363.1998] and [ANSI.X9-62.2005]. One important issue that [IEEE.P1363.1998] and [ANSI.X9-62.2005]. One important issue that
implementers and users must consider is elliptic curve selection. implementers and users must consider is elliptic curve selection.
Guidance on selecting an appropriate elliptic curve size is given in Guidance on selecting an appropriate elliptic curve size is given in
Table 1. Table 1. Security considerations specific to X25519 and X448 are
discussed in section 7 of [RFC7748].
Beyond elliptic curve size, the main issue is elliptic curve Beyond elliptic curve size, the main issue is elliptic curve
structure. As a general principle, it is more conservative to use structure. As a general principle, it is more conservative to use
elliptic curves with as little algebraic structure as possible. elliptic curves with as little algebraic structure as possible.
Thus, random curves are more conservative than special curves such as Thus, random curves are more conservative than special curves such as
Koblitz curves, and curves over F_p with p random are more Koblitz curves, and curves over F_p with p random are more
conservative than curves over F_p with p of a special form (and conservative than curves over F_p with p of a special form, and
curves over F_p with p random might be considered more conservative curves over F_p with p random are considered more conservative than
than curves over F_2^m as there is no choice between multiple fields curves over F_2^m as there is no choice between multiple fields of
of similar size for characteristic 2). Note, however, that algebraic similar size for characteristic 2.
structure can also lead to implementation efficiencies, and
implementers and users may, therefore, need to balance conservatism NEED TO ADD A PARAGRAPH HERE ABOUT WHY X25519/X448 ARE PREFERRABLE TO
against a need for efficiency. Concrete attacks are known against NIST CURVES.
only very few special classes of curves, such as supersingular
curves, and these classes are excluded from the ECC standards that
this document references [IEEE.P1363.1998], [ANSI.X9-62.2005].
Another issue is the potential for catastrophic failures when a Another issue is the potential for catastrophic failures when a
single elliptic curve is widely used. In this case, an attack on the single elliptic curve is widely used. In this case, an attack on the
elliptic curve might result in the compromise of a large number of elliptic curve might result in the compromise of a large number of
keys. Again, this concern may need to be balanced against efficiency keys. Again, this concern may need to be balanced against efficiency
and interoperability improvements associated with widely-used curves. and interoperability improvements associated with widely-used curves.
Substantial additional information on elliptic curve choice can be Substantial additional information on elliptic curve choice can be
found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]. found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4].
All of the key exchange algorithms defined in this document provide All of the key exchange algorithms defined in this document provide
skipping to change at page 27, line 8 skipping to change at page 27, line 29
NOTE: IANA, please update the registries to reflect the new policy. NOTE: IANA, please update the registries to reflect the new policy.
NOTE: RFC editor please delete these two notes prior to publication. NOTE: RFC editor please delete these two notes prior to publication.
IANA, please update these two registries to refer to this document. IANA, please update these two registries to refer to this document.
IANA is requested to assign two values from the NamedCurve registry IANA is requested to assign two values from the NamedCurve registry
with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this
document as reference. IANA has already assigned the value 29 to document as reference. IANA has already assigned the value 29 to
ecdh_x25519, and the value 30 to ecdh_x448(TBD2). ecdh_x25519, and the value 30 to ecdh_x448.
IANA is requested to assign one value from SignatureAlgorithm IANA is requested to assign one value from SignatureAlgorithm
Registry with name eddsa(TBD5) with this document as reference. Registry with name eddsa(TBD5) with this document as reference.
9. Acknowledgements 9. Acknowledgements
Most of the text is this document is taken from [RFC4492], the Most of the text is this document is taken from [RFC4492], the
predecessor of this document. The authors of that document were: predecessor of this document. The authors of that document were:
o Simon Blake-Wilson o Simon Blake-Wilson
o Nelson Bolyard o Nelson Bolyard
o Vipul Gupta o Vipul Gupta
o Chris Hawk o Chris Hawk
o Bodo Moeller o Bodo Moeller
In the predecessor document, the authors acknowledged the In the predecessor document, the authors acknowledged the
contributions of Bill Anderson and Tim Dierks. contributions of Bill Anderson and Tim Dierks.
The author would like to thank Nikos Mavrogiannopoulos, Martin
Thomson, and Tanja Lange for contributions to this document.
10. Version History for This Draft 10. Version History for This Draft
NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION
Changes from draft-ietf-tls-rfc4492bis-03 to draft-nir-tls- Changes from draft-ietf-tls-rfc4492bis-03 to draft-nir-tls-
rfc4492bis-05: rfc4492bis-05:
o Add support for CFRG curves and signatures work. o Add support for CFRG curves and signatures work.
Changes from draft-ietf-tls-rfc4492bis-01 to draft-nir-tls- Changes from draft-ietf-tls-rfc4492bis-01 to draft-nir-tls-
skipping to change at page 28, line 30 skipping to change at page 29, line 14
[CCITT.X690] [CCITT.X690]
International Telephone and Telegraph Consultative International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002. X.690, July 2002.
[CFRG-EdDSA] [CFRG-EdDSA]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-00 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-05
(work in progress), October 2015. (work in progress), March 2016.
[FIPS.186-4] [FIPS.186-4]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186-4, 2013, Signature Standard", FIPS PUB 186-4, 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[PKCS1] RSA Laboratories, "RSA Encryption Standard, Version 1.5", [PKCS1] RSA Laboratories, "RSA Encryption Standard, Version 1.5",
PKCS 1, November 1993. PKCS 1, November 1993.
[PKIX-EdDSA] [PKIX-EdDSA]
Josefsson, S. and N. Mavrogiannopoulos, "Using EdDSA in Josefsson, S. and N. Mavrogiannopoulos, "Using EdDSA in
the Internet X.509 Public Key Infrastructure", draft- the Internet X.509 Public Key Infrastructure", draft-ietf-
josefsson-pkix-eddsa-03 (work in progress), September curdle-pkix-eddsa-00 (work in progress), March 2016.
2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
skipping to change at page 29, line 49 skipping to change at page 30, line 34
[IEEE.P1363.1998] [IEEE.P1363.1998]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Standard Specifications for Public Key Cryptography", "Standard Specifications for Public Key Cryptography",
IEEE Draft P1363, 1998. IEEE Draft P1363, 1998.
[Lenstra_Verheul] [Lenstra_Verheul]
Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293, 2001. Sizes", Journal of Cryptology 14 (2001) 255-293, 2001.
[Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
Diffie-Hellman Key Agreement Protocols", IACR Menezes2008,
December 2008.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492, May 2006.
Appendix A. Equivalent Curves (Informative) Appendix A. Equivalent Curves (Informative)
All of the NIST curves [FIPS.186-4] and several of the ANSI curves All of the NIST curves [FIPS.186-4] and several of the ANSI curves
[ANSI.X9-62.2005] are equivalent to curves listed in Section 5.1.1. [ANSI.X9-62.2005] are equivalent to curves listed in Section 5.1.1.
In the following table, multiple names in one row represent aliases In the following table, multiple names in one row represent aliases
for the same curve. for the same curve.
 End of changes. 28 change blocks. 
58 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/