< draft-ietf-tls-rfc4492bis-12.txt   draft-ietf-tls-rfc4492bis-13.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: August 20, 2017 M. Pegourie-Gonnard Expires: September 3, 2017 M. Pegourie-Gonnard
Independent / PolarSSL Independent / PolarSSL
February 16, 2017 March 2, 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-12 draft-ietf-tls-rfc4492bis-13
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 authentication mechanisms. Digital Signature Algorithm (EdDSA) as authentication mechanisms.
This document obsoletes and replaces RFC 4492.
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 August 20, 2017. This Internet-Draft will expire on September 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 24 skipping to change at page 2, line 26
2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 3 2. Key Exchange Algorithm . . . . . . . . . . . . . . . . . . . 3
2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Client Authentication . . . . . . . . . . . . . . . . . . . . 6 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 6
3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . 7
4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 7 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 7
5. Data Structures and Computations . . . . . . . . . . . . . . 8 5. Data Structures and Computations . . . . . . . . . . . . . . 8
5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8 5.1. Client Hello Extensions . . . . . . . . . . . . . . . . . 8
5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 9 5.1.1. Supported Elliptic Curves Extension . . . . . . . . . 9
5.1.2. Supported Point Formats Extension . . . . . . . . . . 10 5.1.2. Supported Point Formats Extension . . . . . . . . . . 11
5.1.3. The signature_algorithms Extension and EdDSA . . . . 11 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
5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 24 5.11. Public Key Validation . . . . . . . . . . . . . . . . . . 24
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Version History for This Draft . . . . . . . . . . . . . . . 28 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Version History for This Draft . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 31 Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
provides an overview of ECC-based key exchange algorithms for TLS. provides an overview of ECC-based key exchange algorithms for TLS.
Section 3 describes the use of ECC certificates for client Section 3 describes the use of ECC certificates for client
authentication. TLS extensions that allow a client to negotiate the authentication. TLS extensions that allow a client to negotiate the
use of specific curves and point formats are presented in Section 4. use of specific curves and point formats are presented in Section 4.
Section 5 specifies various data structures needed for an ECC-based Section 5 specifies various data structures needed for an ECC-based
handshake, their encoding in TLS messages, and the processing of handshake, their encoding in TLS messages, and the processing of
those messages. Section 6 defines ECC-based cipher suites and those messages. Section 6 defines ECC-based cipher suites and
identifies a small subset of these as recommended for all identifies a small subset of these as recommended for all
implementations of this specification. Section 7 discusses security implementations of this specification. Section 8 discusses security
considerations. Section 8 describes IANA considerations for the name considerations. Section 9 describes IANA considerations for the name
spaces created by this document's predecessor. Section 9 gives spaces created by this document's predecessor. Section 10 gives
acknowledgements. Appendix B provides differences from [RFC4492], acknowledgements. Appendix B provides differences from [RFC4492],
the document that this one replaces. the document that this one replaces.
Implementation of this specification requires familiarity with TLS, Implementation of this specification requires familiarity with TLS,
TLS extensions [RFC4366], and ECC. TLS extensions [RFC4366], and ECC.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 10, line 15 skipping to change at page 10, line 15
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),
reserved (0xFE00..0xFEFF), reserved (0xFE00..0xFEFF),
deprecated(0xFF01..0xFF02), deprecated(0xFF01..0xFF02),
(0xFFFF) (0xFFFF)
} NamedCurve; } NamedCurve;
Note that other specifications have since added other values to this Note that other specifications have since added other values to this
enumeration. enumeration. Some of those values are not curves at all, but finite
field groups. See [RFC7919].
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, groups. The named curves secp256r1, secp384r1, and secp521r1 are
secp384r1, and secp521r1 are specified in SEC 2 [SECG-SEC2]. These specified in SEC 2 [SECG-SEC2]. These curves are also recommended in
curves are also recommended in ANSI X9.62 [ANSI.X9-62.2005] and FIPS ANSI X9.62 [ANSI.X9-62.2005] and FIPS 186-4 [FIPS.186-4]. The rest
186-4 [FIPS.186-4]. The rest of this document refers to these three of this document refers to these three curves as the "NIST curves"
curves as the "NIST curves" because they were originally standardized because they were originally standardized by the National Institute
by the National Institute of Standards and Technology. The curves of Standards and Technology. The curves ecdh_x25519 and ecdh_x448
ecdh_x25519 and ecdh_x448 are defined in [RFC7748]. Values 0xFE00 are defined in [RFC7748]. Values 0xFE00 through 0xFEFF are reserved
through 0xFEFF are reserved for private use. for private use.
The NamedCurve name space is maintained by IANA. See Section 8 for The predecessor of this document also supported explicitly defined
prime and char2 curves, but these are deprecated by this
specification.
The NamedCurve name space is maintained by IANA. See Section 9 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).
As an example, a client that only supports secp256r1 (aka NIST P-256; As an example, a client that only supports secp256r1 (aka NIST P-256;
skipping to change at page 11, line 4 skipping to change at page 11, line 6
As an example, a client that only supports secp256r1 (aka NIST P-256; As an example, a client that only supports secp256r1 (aka NIST P-256;
value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018)
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),
deprecated (1..2), deprecated (1..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
support other formats for curves defined in this specification. For support other formats for curves defined in this specification. For
backwards compatibility purposes, the point format list extension backwards compatibility purposes, the point format list extension
MUST still be included, and contain exactly one value: the MUST still be included, and contain exactly one value: the
uncompressed point format (0). uncompressed point format (0).
The ECPointFormat name space is maintained by IANA. See Section 8 The ECPointFormat name space is maintained by IANA. See Section 9
for information on how new value assignments are added. for information on how new value assignments are added.
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
skipping to change at page 12, line 30 skipping to change at page 12, line 30
parse (for the curve that will appear in its ServerKeyExchange parse (for the curve that will appear in its ServerKeyExchange
message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key
exchange algorithm. exchange algorithm.
Structure of this extension: Structure of this extension:
The server's Supported Point Formats Extension has the same structure The server's Supported Point Formats Extension has the same structure
as the client's Supported Point Formats Extension (see as the client's Supported Point Formats Extension (see
Section 5.1.2). Items in ec_point_format_list here are ordered Section 5.1.2). Items in ec_point_format_list here are ordered
according to the server's preference (favorite choice first). Note according to the server's preference (favorite choice first). Note
that the server may include items that were not found in the client's that the server MAY include items that were not found in the client's
list (e.g., the server may prefer to receive points in compressed list. However, without extensions this specification allows exactly
format even when a client cannot parse this format: the same client one point format, so there is not really any opportunity for
may nevertheless be capable of outputting points in compressed mismatches.
format).
Actions of the sender: Actions of the sender:
A server that selects an ECC cipher suite in response to a A server that selects an ECC cipher suite in response to a
ClientHello message including a Supported Point Formats Extension ClientHello message including a Supported Point Formats Extension
appends this extension (along with others) to its ServerHello appends this extension (along with others) to its ServerHello
message, enumerating the point formats it can parse. The Supported message, enumerating the point formats it can parse. The Supported
Point Formats Extension, when used, MUST contain the value 0 Point Formats Extension, when used, MUST contain the value 0
(uncompressed) as one of the items in the list of point formats. (uncompressed) as one of the items in the list of point formats.
skipping to change at page 13, line 44 skipping to change at page 13, line 44
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
certificate MUST respect the client's choice of elliptic curves; in certificate MUST respect the client's choice of elliptic curves; If
particular, the public key MUST employ a named curve (not the same the client has used a Supported Point Formats Extension, both the
curve as an explicit curve) unless the client has indicated support server's public key point and (in the case of an explicit curve) the
for explicit curves of the appropriate type. If the client has used curve's base point MUST respect the client's choice of point formats.
a Supported Point Formats Extension, both the server's public key (A server that cannot satisfy these requirements MUST NOT choose an
point and (in the case of an explicit curve) the curve's base point ECC cipher suite in its ServerHello message.)
MUST respect the client's choice of point formats. (A server that
cannot satisfy these requirements MUST NOT choose an ECC cipher suite
in its ServerHello message.)
Actions of the receiver: Actions of the receiver:
The client validates the certificate chain, extracts the server's The client validates the certificate chain, extracts the server's
public key, and checks that the key type is appropriate for the public key, and checks that the key type is appropriate for the
negotiated key exchange algorithm. (A possible reason for a fatal negotiated key exchange algorithm. (A possible reason for a fatal
handshake failure is that the client's capabilities for handling handshake failure is that the client's capabilities for handling
elliptic curves and point formats are exceeded; cf. Section 5.1.) elliptic curves and point formats are exceeded; cf. Section 5.1.)
5.4. Server Key Exchange 5.4. Server Key Exchange
skipping to change at page 14, line 42 skipping to change at page 14, line 41
deprecated (1..2), deprecated (1..2),
named_curve (3), named_curve (3),
reserved(248..255) reserved(248..255)
} ECCurveType; } ECCurveType;
The value named_curve indicates that a named curve is used. This The value named_curve indicates that a named curve is used. This
option SHOULD be used when applicable. option SHOULD be used when applicable.
Values 248 through 255 are reserved for private use. Values 248 through 255 are reserved for private use.
The ECCurveType name space is maintained by IANA. See Section 8 for The ECCurveType name space is maintained by IANA. See Section 9 for
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;
skipping to change at page 26, line 16 skipping to change at page 26, line 16
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:
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
7. Security Considerations 7. Implementation Status
Both ECDHE and ECDSA with the NIST curves are widely implemented,
supported in all major browsers and all widely used TLS libraries.
ECDHE with Curve25519 is by now implemented in several browsers and
several TLS libraries including OpenSSL. Curve448 and EdDSA have
working, interoperable implementations, but are not yet as widely
deployed.
8. Security Considerations
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.
skipping to change at page 27, line 9 skipping to change at page 27, line 18
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].
The Introduction of [RFC8032] lists the security, performance, and The Introduction of [RFC8032] lists the security, performance, and
operational advantages of EdDSA signatures over ECDSA signatures operational advantages of EdDSA signatures over ECDSA signatures
using the NIST curves. using the NIST curves.
All of the key exchange algorithms defined in this document provide All of the key exchange algorithms defined in this document provide
forward secrecy. Some of the deprecated key exchange algorithms do forward secrecy. Some of the deprecated key exchange algorithms do
not. not.
8. IANA Considerations 9. IANA Considerations
[RFC4492], the predecessor of this document has already defined the [RFC4492], the predecessor of this document has already defined the
IANA registries for the following: IANA registries for the following:
o Supported Groups Section 5.1 o Supported Groups Section 5.1
o ECPointFormat Section 5.1 o ECPointFormat Section 5.1
o ECCurveType Section 5.4 o ECCurveType Section 5.4
For each name space, this document defines the initial value For each name space, this document defines the initial value
assignments and defines a range of 256 values (NamedCurve) or eight assignments and defines a range of 256 values (NamedCurve) or eight
skipping to change at page 27, line 33 skipping to change at page 27, line 42
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 IANA has already assigned the value 29 to ecdh_x25519, and the value
30 to ecdh_x448. 30 to ecdh_x448.
IANA is requested to assign two values from the NamedCurve registry IANA is requested to assign two values from the TLS
with names ed25519(TBD3) and ed448(TBD4) with this document as SignatureAlgorithm Registry with names ed25519(TBD3) and ed448(TBD4)
reference. To keep compatibility with TLS 1.3, TBD3 should be 0x07, with this document as reference. To keep compatibility with TLS 1.3,
and TBD4 should be 0x08. TBD3 should be 7, and TBD4 should be 8.
IANA is requested to assign one value from the "TLS HashAlgorithm IANA is requested to assign one value from the "TLS HashAlgorithm
Registry" with name Intrinsic(TBD5) and 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. To keep compatibility with TLS 1.3, TBD5 should be 8 and DTLS-OK
should be set to true (Y).
9. Acknowledgements 10. 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 The author would like to thank Nikos Mavrogiannopoulos, Martin
Thomson, and Tanja Lange for contributions to this document. Thomson, and Tanja Lange for contributions to this document.
10. Version History for This Draft 11. 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-
rfc4492bis-03: rfc4492bis-03:
skipping to change at page 28, line 37 skipping to change at page 29, line 5
o Merged errata o Merged errata
o Removed ECDH_RSA and ECDH_ECDSA o Removed ECDH_RSA and ECDH_ECDSA
Changes from RFC 4492 to draft-nir-tls-rfc4492bis-00: Changes from RFC 4492 to draft-nir-tls-rfc4492bis-00:
o Added TLS 1.2 to references. o Added TLS 1.2 to references.
o Moved RFC 4492 authors to acknowledgements. o Moved RFC 4492 authors to acknowledgements.
o Removed list of required reading for ECC. o Removed list of required reading for ECC.
11. References 12. References
11.1. Normative References 12.1. Normative References
[ANSI.X9-62.2005] [ANSI.X9-62.2005]
American National Standards Institute, "Public Key American National Standards Institute, "Public Key
Cryptography for the Financial Services Industry, The Cryptography for the Financial Services Industry, The
Elliptic Curve Digital Signature Algorithm (ECDSA)", Elliptic Curve Digital Signature Algorithm (ECDSA)",
ANSI X9.62, 2005. ANSI X9.62, 2005.
[CCITT.X680] [CCITT.X680]
International Telephone and Telegraph Consultative International Telephone and Telegraph Consultative
Committee, "Abstract Syntax Notation One (ASN.1): Committee, "Abstract Syntax Notation One (ASN.1):
skipping to change at page 30, line 12 skipping to change at page 30, line 30
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, January 2016. for Security", RFC 7748, January 2016.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017. Signature Algorithm (EdDSA)", RFC 8032, January 2017.
[SECG-SEC2] [SECG-SEC2]
CECG, "Recommended Elliptic Curve Domain Parameters", CECG, "Recommended Elliptic Curve Domain Parameters",
SEC 2, 2000. SEC 2, 2000.
11.2. Informative References 12.2. Informative References
[FIPS.180-2] [FIPS.180-2]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/ <http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>. fips180-2.pdf>.
[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),
skipping to change at page 30, line 38 skipping to change at page 31, line 9
IEEE Draft P1363, 1998. IEEE Draft P1363, 1998.
[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.
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman
Ephemeral Parameters for Transport Layer Security (TLS)",
RFC 7919, DOI 10.17487/RFC7919, August 2016,
<http://www.rfc-editor.org/info/rfc7919>.
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.
Curve names chosen by different standards organizations Curve names chosen by different standards organizations
+-----------+------------+------------+ +-----------+------------+------------+
 End of changes. 27 change blocks. 
56 lines changed or deleted 78 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/