< draft-ietf-tls-rfc4492bis-09.txt   draft-ietf-tls-rfc4492bis-10.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: May 2, 2017 M. Pegourie-Gonnard Expires: July 15, 2017 M. Pegourie-Gonnard
Independent / PolarSSL Independent / PolarSSL
October 29, 2016 January 11, 2017
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-09 draft-ietf-tls-rfc4492bis-10
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 authentication mechanisms.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 2, 2017. This Internet-Draft will expire on July 15, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 4 2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 3
2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Client Authentication . . . . . . . . . . . . . . . . . . . . 7 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 6
3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7
4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 8 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 7
5. Data Structures and Computations . . . . . . . . . . . . . . 8 5. Data Structures and Computations . . . . . . . . . . . . . . 8
5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 9 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8
5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 10 5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 9
5.1.2. Supported Point Formats Extension . . . . . . . . . . 11 5.1.2. Supported Point Formats Extension . . . . . . . . . . 10
5.1.3. The signature_algorithms Extension and EdDSA . . . . 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.4.1. Uncompressed Point Format for NIST curves . . . . . . 17 5.4.1. Uncompressed Point Format for NIST curves . . . . . . 17
5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 18 5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 18
5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 19 5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 19
5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 20 5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 20
5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 21 5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 21
5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 23 5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 23
5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 23 5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 23
skipping to change at page 3, line 7 skipping to change at page 3, line 7
10. Version History for This Draft . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 30 Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 30
Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 31 Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
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.
+-----------+-------+------------+
| Symmetric | ECC | DH/DSA/RSA |
+-----------+-------+------------+
| 80 | >=158 | 1024 |
| 112 | >=221 | 2048 |
| 128 | >=252 | 3072 |
| 192 | >=379 | 7680 |
| 256 | >=506 | 15360 |
+-----------+-------+------------+
Table 1: Comparable Key Sizes (in bits)
Smaller key sizes result in savings for power, memory, bandwidth, and
computational cost that make ECC especially attractive for
constrained environments.
This document describes additions to TLS to support ECC, applicable This document describes additions to TLS to support ECC, applicable
to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246]. The to TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246]. The
use of ECC in TLS 1.3 is defined in [I-D.ietf-tls-tls13], and is use of ECC in TLS 1.3 is defined in [I-D.ietf-tls-tls13], and is
explicitly out of scope for this document. In particular, this explicitly out of scope for this document. In particular, this
document defines: document defines:
o the use of the Elliptic Curve Diffie-Hellman key agreement scheme o the use of the Elliptic Curve Diffie-Hellman key agreement scheme
with ephemeral keys to establish the TLS premaster secret, and with ephemeral keys to establish the TLS premaster secret, and
o the use of ECDSA certificates for authentication of TLS peers. o the use of ECDSA certificates for authentication of TLS peers.
skipping to change at page 4, line 27 skipping to change at page 3, line 51
2. Key Exchange Algorithm 2. Key Exchange Algorithm
This document defines three new ECC-based key exchange algorithms for This document defines three new ECC-based key exchange algorithms for
TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS
premaster secret, and they differ only in the mechanism (if any) used premaster secret, and they differ only in the mechanism (if any) used
to authenticate them. The derivation of the TLS master secret from to authenticate them. The derivation of the TLS master secret from
the premaster secret and the subsequent generation of bulk the premaster secret and the subsequent generation of bulk
encryption/MAC keys and initialization vectors is independent of the encryption/MAC keys and initialization vectors is independent of the
key exchange algorithm and not impacted by the introduction of ECC. key exchange algorithm and not impacted by the introduction of ECC.
Table 2 summarizes the new key exchange algorithms. All of these key Table 1 summarizes the new key exchange algorithms. All of these key
exchange algorithms provide forward secrecy. exchange algorithms provide forward secrecy.
+-------------+------------------------------------------------+ +-------------+------------------------------------------------+
| Algorithm | Description | | Algorithm | Description |
+-------------+------------------------------------------------+ +-------------+------------------------------------------------+
| ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. | | ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. |
| ECDHE_RSA | Ephemeral ECDH with RSA signatures. | | ECDHE_RSA | Ephemeral ECDH with RSA signatures. |
| ECDH_anon | Anonymous ephemeral ECDH, no signatures. | | ECDH_anon | Anonymous ephemeral ECDH, no signatures. |
+-------------+------------------------------------------------+ +-------------+------------------------------------------------+
Table 2: ECC Key Exchange Algorithms Table 1: ECC Key Exchange Algorithms
These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon,
respectively. respectively.
With ECDHE_RSA, a server can reuse its existing RSA certificate and With ECDHE_RSA, a server can reuse its existing RSA certificate and
easily comply with a constrained client's elliptic curve preferences easily comply with a constrained client's elliptic curve preferences
(see Section 4). However, the computational cost incurred by a (see Section 4). However, the computational cost incurred by a
server is higher for ECDHE_RSA than for the traditional RSA key server is higher for ECDHE_RSA than for the traditional RSA key
exchange, which does not provide forward secrecy. exchange, which does not provide forward secrecy.
The anonymous key exchange algorithm does not provide authentication The anonymous key exchange algorithm does not provide authentication
of the server or the client. Like other anonymous TLS key exchanges, of the server or the client. Like other anonymous TLS key exchanges,
it is subject to man-in-the-middle attacks. Implementations of this it is subject to man-in-the-middle attacks. Applications using TLS
algorithm SHOULD provide authentication by other means. with 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.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
ServerHello ServerHello
Certificate* Certificate*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest*+ CertificateRequest*+
<-------- ServerHelloDone <-------- ServerHelloDone
Certificate*+ Certificate*+
skipping to change at page 7, line 19 skipping to change at page 6, line 27
RFC 5246. RFC 5246.
3. Client Authentication 3. Client Authentication
This document defines a client authentication mechanism, named after This document defines a client authentication mechanism, named after
the type of client certificate involved: ECDSA_sign. The ECDSA_sign the type of client certificate involved: ECDSA_sign. The ECDSA_sign
mechanism is usable with any of the non-anonymous ECC key exchange mechanism is usable with any of the non-anonymous ECC key exchange
algorithms described in Section 2 as well as other non-anonymous algorithms described in Section 2 as well as other non-anonymous
(non-ECC) key exchange algorithms defined in TLS. (non-ECC) key exchange algorithms defined in TLS.
Note that client certificates with EdDSA public keys use this
mechanism.
The server can request ECC-based client authentication by including The server can request ECC-based client authentication by including
this certificate type in its CertificateRequest message. The client this certificate type in its CertificateRequest message. The client
must check if it possesses a certificate appropriate for the method must check if it possesses a certificate appropriate for the method
suggested by the server and is willing to use it for authentication. suggested by the server and is willing to use it for authentication.
If these conditions are not met, the client should send a client If these conditions are not met, the client should send a client
Certificate message containing no certificates. In this case, the Certificate message containing no certificates. In this case, the
ClientKeyExchange should be sent as described in Section 2, and the ClientKeyExchange should be sent as described in Section 2, and the
CertificateVerify should not be sent. If the server requires client CertificateVerify should not be sent. If the server requires client
authentication, it may respond with a fatal handshake failure alert. authentication, it may respond with a fatal handshake failure alert.
skipping to change at page 8, line 7 skipping to change at page 7, line 16
To use this authentication mechanism, the client MUST possess a To use this authentication mechanism, the client MUST possess a
certificate containing an ECDSA- or EdDSA-capable public key. certificate containing an ECDSA- or EdDSA-capable public key.
The client proves possession of the private key corresponding to the The client proves possession of the private key corresponding to the
certified key by including a signature in the CertificateVerify certified key by including a signature in the CertificateVerify
message as described in Section 5.8. message as described in Section 5.8.
4. TLS Extensions for ECC 4. TLS Extensions for ECC
Two new TLS extensions are defined in this specification: (i) the Two TLS extensions are defined in this specification: (i) the
Supported Elliptic Curves Extension, and (ii) the Supported Point Supported Elliptic Curves Extension, and (ii) the Supported Point
Formats Extension. These allow negotiating the use of specific Formats Extension. These allow negotiating the use of specific
curves and point formats (e.g., compressed vs. uncompressed, curves and point formats (e.g., compressed vs. uncompressed,
respectively) during a handshake starting a new session. These respectively) during a handshake starting a new session. These
extensions are especially relevant for constrained clients that may extensions are especially relevant for constrained clients that may
only support a limited number of curves or point formats. They only support a limited number of curves or point formats. They
follow the general approach outlined in [RFC4366]; message details follow the general approach outlined in [RFC4366]; message details
are specified in Section 5. The client enumerates the curves it are specified in Section 5. The client enumerates the curves it
supports and the point formats it can parse by including the supports and the point formats it can parse by including the
appropriate extensions in its ClientHello message. The server appropriate extensions in its ClientHello message. The server
skipping to change at page 9, line 26 skipping to change at page 8, line 35
proposes ECC cipher suites. proposes ECC cipher suites.
Meaning of these extensions: Meaning of these extensions:
These extensions allow a client to enumerate the elliptic curves it These extensions allow a client to enumerate the elliptic curves it
supports and/or the point formats it can parse. supports and/or the point formats it can parse.
Structure of these extensions: Structure of these extensions:
The general structure of TLS extensions is described in [RFC4366], The general structure of TLS extensions is described in [RFC4366],
and this specification adds two new types to ExtensionType. and this specification adds two types to ExtensionType.
enum { enum {
elliptic_curves(10), elliptic_curves(10),
ec_point_formats(11) ec_point_formats(11)
} ExtensionType; } ExtensionType;
elliptic_curves (Supported Elliptic Curves Extension): Indicates the o elliptic_curves (Supported Elliptic Curves Extension): Indicates
set of elliptic curves supported by the client. For this the set of elliptic curves supported by the client. For this
extension, the opaque extension_data field contains extension, the opaque extension_data field contains
EllipticCurveList. See Section 5.1.1 for details. EllipticCurveList. See Section 5.1.1 for details.
ec_point_formats (Supported Point Formats Extension): Indicates the o ec_point_formats (Supported Point Formats Extension): Indicates
set of point formats that the client can parse. For this the set of point formats that the client can parse. For this
extension, the opaque extension_data field contains extension, the opaque extension_data field contains
ECPointFormatList. See Section 5.1.2 for details. ECPointFormatList. See Section 5.1.2 for details.
Actions of the sender: Actions of the sender:
A client that proposes ECC cipher suites in its ClientHello message A client that proposes ECC cipher suites in its ClientHello message
appends these extensions (along with any others), enumerating the appends these extensions (along with any others), enumerating the
curves it supports and the point formats it can parse. Clients curves it supports and the point formats it can parse. Clients
SHOULD send both the Supported Elliptic Curves Extension and the SHOULD send both the Supported Elliptic Curves Extension and the
Supported Point Formats Extension. If the Supported Point Formats Supported Point Formats Extension. If the Supported Point Formats
skipping to change at page 10, line 36 skipping to change at page 9, line 44
cipher suites. cipher suites.
5.1.1. Supported Elliptic Curves Extension 5.1.1. Supported Elliptic Curves Extension
RFC 4492 defined 25 different curves in the NamedCurve registry (now RFC 4492 defined 25 different curves in the NamedCurve registry (now
renamed the "Supported Groups" registry, although the enumeration renamed the "Supported Groups" registry, although the enumeration
below is still named NamedCurve) for use in TLS. Only three have below is still named NamedCurve) for use in TLS. Only three have
seen much use. This specification is deprecating the rest (with seen much use. This specification is deprecating the rest (with
numbers 1-22). This specification also deprecates the explicit numbers 1-22). This specification also deprecates the explicit
curves with identifiers 0xFF01 and 0xFF02. It also adds the new curves with identifiers 0xFF01 and 0xFF02. It also adds the new
curves defined in [RFC7748] and [CFRG-EdDSA]. The end result is as curves defined in [RFC7748]. The end result is as follows:
follows:
enum { enum {
deprecated(1..22), deprecated(1..22),
secp256r1 (23), secp384r1 (24), secp521r1 (25), secp256r1 (23), secp384r1 (24), secp521r1 (25),
ecdh_x25519(29), ecdh_x448(30), ecdh_x25519(29), ecdh_x448(30),
eddsa_ed25519(TBD3), eddsa_ed448(TBD4),
reserved (0xFE00..0xFEFF), reserved (0xFE00..0xFEFF),
deprecated(0xFF01..0xFF02), deprecated(0xFF01..0xFF02),
(0xFFFF) (0xFFFF)
} NamedCurve; } NamedCurve;
Note that other specification have since added other values to this Note that other specifications 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]. The rest of this document refers to these three 186-4 [FIPS.186-4]. The rest of this document refers to these three
curves as the "NIST curves" because they were originally standardized curves as the "NIST curves" because they were originally standardized
by the National Institute of Standards and Technology. The curves by the National Institute of Standards and Technology. The curves
ecdh_x25519 and ecdh_x448 are defined in [RFC7748]. eddsa_ed25519 and ecdh_x25519 and ecdh_x448 are defined in [RFC7748]. Values 0xFE00
eddsa_ed448 are signature-only curves defined in [CFRG-EdDSA]. through 0xFEFF are reserved for private use.
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 12, line 17 skipping to change at page 11, line 34
Items in ec_point_format_list are ordered according to the client's Items in ec_point_format_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
A client compliant with this specification that supports no other A client compliant with this specification that supports no other
curves MUST send the following octets; note that the first two octets curves MUST send the following octets; note that the first two octets
indicate the extension type (Supported Point Formats Extension): indicate the extension type (Supported Point Formats Extension):
00 0B 00 02 01 00 00 0B 00 02 01 00
5.1.3. The signature_algorithms Extension and EdDSA
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.
5.2. Server Hello Extension 5.2. Server Hello Extension
This section specifies a TLS extension that can be included with the This section specifies a TLS extension that can be included with the
ServerHello message as described in [RFC4366], the Supported Point ServerHello message as described in [RFC4366], the Supported Point
Formats Extension. Formats Extension.
When this extension is sent: When this extension is sent:
The Supported Point Formats Extension is included in a ServerHello The Supported Point Formats Extension is included in a ServerHello
message in response to a ClientHello message containing the Supported message in response to a ClientHello message containing the Supported
skipping to change at page 13, line 45 skipping to change at page 13, line 33
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| Algorithm | Server Certificate Type | | Algorithm | Server Certificate Type |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
| ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable | | ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable |
| | public key. | | | public key. |
| ECDHE_RSA | Certificate MUST contain an RSA public key | | ECDHE_RSA | Certificate MUST contain an RSA public key |
| | authorized for use in digital signatures. | | | authorized for use in digital signatures. |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
Table 3: Server Certificate Types Table 2: Server Certificate Types
Structure of this message: Structure of this message:
Identical to the TLS Certificate format. Identical to the TLS Certificate format.
Actions of the sender: Actions of the sender:
The server constructs an appropriate certificate chain and conveys it The server constructs an appropriate certificate chain and conveys it
to the client in the Certificate message. If the client has used a to the client in the Certificate message. If the client has used a
Supported Elliptic Curves Extension, the public key in the server's Supported Elliptic Curves Extension, the public key in the server's
skipping to change at page 15, line 18 skipping to change at page 15, line 5
information on how new value assignments are added. information on how new value assignments are added.
RFC 4492 had a specification for an ECCurve structure and an RFC 4492 had a specification for an ECCurve structure and an
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 point: This is the byte string representation of an elliptic curve
following the conversion routine in Section 4.3.6 of point 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, compressed, or hybrid format, but this point in uncompressed, compressed, or hybrid format, but this
specification deprecates all but the uncompressed format. For the specification deprecates all but the uncompressed format. For the
NIST curves, the format is repeated in Section 5.4.1 for convenience. NIST curves, the format is repeated in Section 5.4.1 for convenience.
For the X25519 and X448 curves, the only valid representation is the For the X25519 and X448 curves, the only valid representation is the
one specified in [RFC7748] - a 32- or 56-octet representation of 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 u value of the point. This structure MUST NOT be used with Ed25519
and Ed448 public keys. 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. curve_type: This identifies the type of the elliptic curve domain
parameters.
Specifies a recommended set of elliptic curve domain parameters. All namedCurve: Specifies a recommended set of elliptic curve domain
those values of NamedCurve are allowed that refer to a curve capable parameters. All those values of NamedCurve are allowed that refer to
of Diffie-Hellman. With the deprecation of the explicit curves, this a curve capable of Diffie-Hellman. With the deprecation of the
now includes all values of NamedCurve except eddsa_ed25519(TBD3) and explicit curves, this now includes all of the NamedCurve values.
eddsa_ed448(TBD4).
struct { struct {
ECParameters curve_params; ECParameters curve_params;
ECPoint public; ECPoint public;
} ServerECDHParams; } ServerECDHParams;
Specifies the elliptic curve domain parameters associated with the curve_params: Specifies the elliptic curve domain parameters
ECDH public key. associated with the ECDH public key.
The ephemeral ECDH public key. public: The ephemeral ECDH public key.
The ServerKeyExchange message is extended as follows. The ServerKeyExchange message is extended as follows.
enum { enum {
ec_diffie_hellman ec_diffie_hellman
} KeyExchangeAlgorithm; } KeyExchangeAlgorithm;
ec_diffie_hellman: Indicates the ServerKeyExchange message contains o ec_diffie_hellman: Indicates the ServerKeyExchange message
an ECDH public key. contains an ECDH public key.
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: case ec_diffie_hellman:
ServerECDHParams params; ServerECDHParams params;
Signature signed_params; Signature signed_params;
} ServerKeyExchange; } ServerKeyExchange;
params: Specifies the ECDH public key and associated domain o params: Specifies the ECDH public key and associated domain
parameters. parameters.
signed_params: A hash of the params, with the signature appropriate o signed_params: A hash of the params, with the signature
to that hash applied. The private key corresponding to the appropriate to that hash applied. The private key corresponding
certified public key in the server's Certificate message is used to the certified public key in the server's Certificate message is
for signing. used for signing.
enum { enum {
ecdsa(3), ecdsa(3),
eddsa(TBD5) ed25519(TBD3)
ed448(TBD4)
} SignatureAlgorithm; } SignatureAlgorithm;
select (SignatureAlgorithm) { select (SignatureAlgorithm) {
case ecdsa: case ecdsa:
digitally-signed struct { digitally-signed struct {
opaque sha_hash[sha_size]; opaque sha_hash[sha_size];
}; };
case eddsa: case ed25519,ed448:
digitally-signed struct { digitally-signed struct {
opaque rawdata[rawdata_size]; opaque rawdata[rawdata_size];
}; };
} Signature; } Signature;
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;
skipping to change at page 18, line 42 skipping to change at page 18, line 38
The TLS CertificateRequest message is extended as follows. The TLS CertificateRequest message is extended as follows.
enum { enum {
ecdsa_sign(64), ecdsa_sign(64),
rsa_fixed_ecdh(65), rsa_fixed_ecdh(65),
ecdsa_fixed_ecdh(66), ecdsa_fixed_ecdh(66),
(255) (255)
} ClientCertificateType; } ClientCertificateType;
ecdsa_sign, etc. Indicates that the server would like to use the o ecdsa_sign, etc.: Indicates that the server would like to use the
corresponding client authentication method specified in Section 3. corresponding client authentication method specified in Section 3.
Actions of the sender: Actions of the sender:
The server decides which client authentication methods it would like The server decides which client authentication methods it would like
to use, and conveys this information to the client using the format to use, and conveys this information to the client using the format
defined above. defined above.
Actions of the receiver: Actions of the receiver:
skipping to change at page 19, line 51 skipping to change at page 19, line 47
| ECDSA_sign | Certificate MUST contain an ECDSA- or EdDSA- | | ECDSA_sign | Certificate MUST contain an ECDSA- or EdDSA- |
| | capable public key. | | | capable public key. |
| ECDSA_fixed_ECDH | Certificate MUST contain an ECDH-capable | | ECDSA_fixed_ECDH | Certificate MUST contain an ECDH-capable |
| | public key on the same elliptic curve as the | | | public key on the same elliptic curve as the |
| | server's long-term ECDH key. | | | server's long-term ECDH key. |
| RSA_fixed_ECDH | The same as ECDSA_fixed_ECDH. The codepoints | | RSA_fixed_ECDH | The same as ECDSA_fixed_ECDH. The codepoints |
| | meant different things, but due to changes in | | | meant different things, but due to changes in |
| | TLS 1.2, both mean the same thing now. | | | TLS 1.2, both mean the same thing now. |
+------------------+------------------------------------------------+ +------------------+------------------------------------------------+
Table 4: Client Certificate Types Table 3: Client Certificate Types
Structure of this message: Structure of this message:
Identical to the TLS client Certificate format. Identical to the TLS client Certificate format.
Actions of the sender: Actions of the sender:
The client constructs an appropriate certificate chain, and conveys The client constructs an appropriate certificate chain, and conveys
it to the server in the Certificate message. it to the server in the Certificate message.
skipping to change at page 20, line 44 skipping to change at page 20, line 40
Structure of this message: Structure of this message:
The TLS ClientKeyExchange message is extended as follows. The TLS ClientKeyExchange message is extended as follows.
enum { enum {
implicit, implicit,
explicit explicit
} PublicValueEncoding; } PublicValueEncoding;
implicit, explicit: For ECC cipher suites, this indicates whether o implicit, explicit: For ECC cipher suites, this indicates whether
the client's ECDH public key is in the client's certificate the client's ECDH public key is in the client's certificate
("implicit") or is provided, as an ephemeral ECDH public key, in ("implicit") or is provided, as an ephemeral ECDH public key, in
the ClientKeyExchange message ("explicit"). (This is "explicit" the ClientKeyExchange message ("explicit"). (This is "explicit"
in ECC cipher suites except when the client uses the in ECC cipher suites except when the client uses the
ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
mechanism.) mechanism.)
struct { struct {
select (PublicValueEncoding) { select (PublicValueEncoding) {
case implicit: struct { }; case implicit: struct { };
case explicit: ECPoint ecdh_Yc; case explicit: ECPoint ecdh_Yc;
} ecdh_public; } ecdh_public;
} ClientECDiffieHellmanPublic; } ClientECDiffieHellmanPublic;
ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte o ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte
string ECPoint.point, which may represent an elliptic curve point string ECPoint.point, which may represent an elliptic curve point
in uncompressed or compressed format. Curves eddsa_ed25519 and in uncompressed or compressed format. Curves eddsa_ed25519 and
eddsa_ed448 MUST NOT be used here. Here, the format MUST conform eddsa_ed448 MUST NOT be used here. Here, the format MUST conform
to what the server has requested through a Supported Point Formats to what the server has requested through a Supported Point Formats
Extension if this extension was used, and MUST be uncompressed if Extension if this extension was used, and MUST be uncompressed if
this extension was not used. this extension was not used.
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic; case ec_diffie_hellman: ClientECDiffieHellmanPublic;
skipping to change at page 25, line 46 skipping to change at page 25, line 46
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } | | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } | | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } | | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } |
| | | | | |
| TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } | | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } |
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } | | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } |
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } | | TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } |
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } | | TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } |
+---------------------------------------+----------------+ +---------------------------------------+----------------+
Table 5: TLS ECC cipher suites Table 4: TLS ECC cipher suites
The key exchange method, cipher, and hash algorithm for each of these The key exchange method, cipher, and hash algorithm for each of these
cipher suites are easily determined by examining the name. Ciphers cipher suites are easily determined by examining the name. Ciphers
(other than AES ciphers) and hash algorithms are defined in [RFC2246] (other than AES ciphers) and hash algorithms are defined in [RFC2246]
and [RFC4346]. AES ciphers are defined in [RFC5246]. and [RFC4346]. AES ciphers are defined in [RFC5246].
Server implementations SHOULD support all of the following cipher Server implementations SHOULD support all of the following cipher
suites, and client implementations SHOULD support at least one of suites, and client implementations SHOULD support at least one of
them: them:
skipping to change at page 27, line 26 skipping to change at page 27, line 26
values (ECPointFormat and ECCurveType) reserved for Private Use. The values (ECPointFormat and ECCurveType) reserved for Private Use. The
policy for any additional assignments is "Specification Required". policy for any additional assignments is "Specification Required".
The previous version of this document required IETF review. The previous version of this document required IETF review.
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 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 IANA is requested to assign two values from the NamedCurve registry
with names eddsa_ed25519(TBD3) and eddsa_ed448(TBD4) with this with names ed25519(TBD3) and ed448(TBD4) with this document as
document as reference. IANA has already assigned the value 29 to reference. To keep compatibility with TLS 1.3, TBD3 should be 0x07,
ecdh_x25519, and the value 30 to ecdh_x448. and TBD4 should be 0x08.
IANA is requested to assign one value from SignatureAlgorithm IANA is requested to assign one value from the "TLS HashAlgorithm
Registry with name eddsa(TBD5) with this document as reference. Registry" with name Intrinsic(TBD5) and this document as reference.
To keep compatibility with TLS 1.3, TBD5 should be 0x08.
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
skipping to change at page 30, line 30 skipping to change at page 30, line 30
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-18 (work in progress), Version 1.3", draft-ietf-tls-tls13-18 (work in progress),
October 2016. October 2016.
[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, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293, 2001.
[Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In [Menezes] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
Diffie-Hellman Key Agreement Protocols", IACR Menezes2008, Diffie-Hellman Key Agreement Protocols", IACR Menezes2008,
December 2008. 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)
skipping to change at page 31, line 37 skipping to change at page 31, line 37
| secp192k1 | | | | secp192k1 | | |
| secp192r1 | prime192v1 | NIST P-192 | | secp192r1 | prime192v1 | NIST P-192 |
| secp224k1 | | | | secp224k1 | | |
| secp224r1 | | NIST P-224 | | secp224r1 | | NIST P-224 |
| secp256k1 | | | | secp256k1 | | |
| secp256r1 | prime256v1 | NIST P-256 | | secp256r1 | prime256v1 | NIST P-256 |
| secp384r1 | | NIST P-384 | | secp384r1 | | NIST P-384 |
| secp521r1 | | NIST P-521 | | secp521r1 | | NIST P-521 |
+-----------+------------+------------+ +-----------+------------+------------+
Table 6: Equivalent curves defined by SECG, ANSI, and NIST Table 5: Equivalent curves defined by SECG, ANSI, and NIST
Appendix B. Differences from RFC 4492 Appendix B. Differences from RFC 4492
o Added TLS 1.2 o Added TLS 1.2
o Merged Errata o Merged Errata
o Removed the ECDH key exchange algorithms: ECDH_RSA and ECDH_ECDSA o Removed the ECDH key exchange algorithms: ECDH_RSA and ECDH_ECDSA
o Deprecated a bunch of ciphersuites: o Deprecated a bunch of ciphersuites:
TLS_ECDH_ECDSA_WITH_NULL_SHA TLS_ECDH_ECDSA_WITH_NULL_SHA
TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA
 End of changes. 44 change blocks. 
101 lines changed or deleted 88 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/