< draft-ietf-tls-rfc4492bis-02.txt   draft-ietf-tls-rfc4492bis-03.txt >
TLS Working Group Y. Nir TLS Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track March 9, 2015 Intended status: Standards Track July 6, 2015
Expires: September 10, 2015 Expires: January 7, 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-02 draft-ietf-tls-rfc4492bis-03
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) as a new use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
authentication mechanism. authentication mechanism.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 10, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 22 skipping to change at page 2, line 22
2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 11
5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 13 5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 12
5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 14 5.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 13
5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 18 5.5. Certificate Request . . . . . . . . . . . . . . . . . . . 17
5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 19 5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 18
5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 20 5.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 19
5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 22 5.8. Certificate Verify . . . . . . . . . . . . . . . . . . . 21
5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 23 5.9. Elliptic Curve Certificates . . . . . . . . . . . . . . . 22
5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 23 5.10. ECDH, ECDSA, and RSA Computations . . . . . . . . . . . . 22
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10. Version History for This Draft . . . . . . . . . . . . . . . 26 10. Version History for This Draft . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 28 Appendix A. Equivalent Curves (Informative) . . . . . . . . . . 27
Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 29 Appendix B. Differences from RFC 4492 . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Elliptic Curve Cryptography (ECC) is emerging as an attractive Elliptic Curve Cryptography (ECC) is emerging 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 4, line 37 skipping to change at page 4, line 37
| ECDHE_ECDSA | Ephemeral ECDH with ECDSA signatures. | | ECDHE_ECDSA | Ephemeral ECDH with ECDSA signatures. |
| ECDHE_RSA | Ephemeral ECDH with RSA signatures. | | ECDHE_RSA | Ephemeral ECDH with RSA signatures. |
| ECDH_anon | Anonymous ECDH, no signatures. | | ECDH_anon | Anonymous ECDH, no signatures. |
+-------------+---------------------------------------+ +-------------+---------------------------------------+
Table 2: ECC Key Exchange Algorithms Table 2: ECC Key Exchange Algorithms
The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
secrecy. With ECDHE_RSA, a server can reuse its existing RSA secrecy. With ECDHE_RSA, a server can reuse its existing RSA
certificate and easily comply with a constrained client's elliptic certificate and easily comply with a constrained client's elliptic
curve preferences (see Section 4). However, the computational cost curve p references (see Section 4). However, the computational cost
incurred by a server is higher for ECDHE_RSA than for the traditional incurred by a server is higher for ECDHE_RSA than for the traditional
RSA key exchange, which does not provide forward secrecy. RSA key 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. Implementations of this
algorithm SHOULD provide authentication by other means. algorithm SHOULD provide authentication by other means.
Note that there is no structural difference between ECDH and ECDSA Note that there is no structural difference between ECDH and ECDSA
keys. A certificate issuer may use X.509 v3 keyUsage and keys. A certificate issuer may use X.509 v3 keyUsage and
skipping to change at page 5, line 32 skipping to change at page 5, line 32
+ message is not sent unless client authentication + message is not sent unless client authentication
is desired is desired
Figure 1: Message flow in a full TLS handshake Figure 1: Message flow in a full TLS handshake
Figure 1 shows all messages involved in the TLS key establishment Figure 1 shows all messages involved in the TLS key establishment
protocol (aka full handshake). The addition of ECC has direct impact protocol (aka full handshake). The addition of ECC has direct impact
only on the ClientHello, the ServerHello, the server's Certificate only on the ClientHello, the ServerHello, the server's Certificate
message, the ServerKeyExchange, the ClientKeyExchange, the message, the ServerKeyExchange, the ClientKeyExchange, the
CertificateRequest, the client's Certificate message, and the CertificateRequest, the client's Certificate message, and the
CertificateVerify. Next, we describe each ECC key exchange algorithm CertificateVerify. Next, we describe the ECC key exchange algorithm
in greater detail in terms of the content and processing of these in greater detail in terms of the content and processing of these
messages. For ease of exposition, we defer discussion of client messages. For ease of exposition, we defer discussion of client
authentication and associated messages (identified with a + in authentication and associated messages (identified with a + in
Figure 1) until Section 3 and of the optional ECC-specific extensions Figure 1) until Section 3 and of the optional ECC-specific extensions
(which impact the Hello messages) until Section 4. (which impact the Hello messages) until Section 4.
2.1. ECDHE_ECDSA 2.1. ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
capable public key and be signed with ECDSA. capable public key and be signed with ECDSA.
skipping to change at page 10, line 12 skipping to change at page 10, line 12
Extension, does not understand the Supported Point Formats Extension, Extension, does not understand the Supported Point Formats Extension,
or is unable to complete the ECC handshake while restricting itself or is unable to complete the ECC handshake while restricting itself
to the enumerated curves and point formats, it MUST NOT negotiate the to the enumerated curves and point formats, it MUST NOT negotiate the
use of an ECC cipher suite. Depending on what other cipher suites use of an ECC cipher suite. Depending on what other cipher suites
are proposed by the client and supported by the server, this may are proposed by the client and supported by the server, this may
result in a fatal handshake failure alert due to the lack of common result in a fatal handshake failure alert due to the lack of common
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 for
use in TLS. Only three have seen any use. This specification is
deprecating the rest (with numbers 1-22). This specification also
deprecates the explicit curves with identifiers 0xFF01 and 0xFF02.
This leaves only the following:
enum { enum {
sect163k1 (1), sect163r1 (2), sect163r2 (3), deprecated(1..22),
sect193r1 (4), sect193r2 (5), sect233k1 (6), secp256r1 (23), secp384r1 (24), secp521r1 (25),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25),
reserved (0xFE00..0xFEFF), reserved (0xFE00..0xFEFF),
arbitrary_explicit_prime_curves(0xFF01), deprecated(0xFF01..0xFF02),
arbitrary_explicit_char2_curves(0xFF02),
(0xFFFF) (0xFFFF)
} NamedCurve; } NamedCurve;
sect163k1, etc: Indicates support of the corresponding named curve or Note that other specification have since added other values to this
enumeration.
secp256r1, etc: Indicates support of the corresponding named curve or
class of explicitly defined curves. The named curves defined here class of explicitly defined curves. The named curves defined here
are those specified in SEC 2 [SECG-SEC2]. Note that many of these are those specified in SEC 2 [SECG-SEC2]. Note that many of these
curves are also recommended in ANSI X9.62 [ANSI.X9-62.2005] and FIPS curves are also recommended in ANSI X9.62 [ANSI.X9-62.2005] and FIPS
186-4 [FIPS.186-4]. Values 0xFE00 through 0xFEFF are reserved for 186-4 [FIPS.186-4]. Values 0xFE00 through 0xFEFF are reserved for
private use. Values 0xFF01 and 0xFF02 indicate that the client private use.
supports arbitrary prime and characteristic-2 curves, respectively
(the curve parameters must be encoded explicitly in ECParameters).
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<1..2^16-1> NamedCurve elliptic_curve_list<1..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 secp192r1 (aka NIST P-192; As an example, a client that only supports secp256r1 (aka NIST P-256;
value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018)
and prefers to use secp192r1 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 13 00 15 00 0A 00 06 00 04 00 17 00 18
A client that supports arbitrary explicit characteristic-2 curves
(value 0xFF02) would include an extension consisting of the following
octets:
00 0A 00 04 00 02 FF 02
5.1.2. Supported Point Formats Extension 5.1.2. Supported Point Formats Extension
enum { uncompressed (0), ansiX962_compressed_prime (1), enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_compressed_char2 (2), reserved (248..255) ansiX962_compressed_char2 (2), 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 are included in the definition of ECPointFormat Three point formats were included in the definition of ECPointFormat
above. The uncompressed point format is the default format in that above. This specification deprecates all but the uncompressed point
implementations of this document MUST support it for all of their format. Implementations of this document MUST support the
supported curves. Compressed point formats reduce bandwidth by uncompressed format for all of their supported curves, and MUST
including only the x-coordinate and a single bit of the y-coordinate support no other formats for curves defined in this specification.
of the point. Implementations of this document MAY support the For backwards compatibility purposes, the point format list extension
ansiX962_compressed_prime and ansiX962_compressed_char2 formats, MUST still be included, and contain exactly one value: the
where the former applies only to prime curves and the latter applies uncomptessed point format (0).
only to characteristic-2 curves. (These formats are specified in
[ANSI.X9-62.2005].) Values 248 through 255 are reserved for private
use.
The ECPointFormat name space is maintained by IANA. See Section 8 The ECPointFormat name space is maintained by IANA. See Section 8
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 that can parse only the uncompressed point format (value 0) A client compliant with this specification that supports no other
includes an extension consisting of the following octets; note that curves MUST send the following octets; note that the first two octets
the first two octets indicate the extension type (Supported Point indicate the extension type (Supported Point Formats Extension):
Formats Extension):
00 0B 00 02 01 00 00 0B 00 02 01 00
A client that in the case of prime fields prefers the compressed
format (ansiX962_compressed_prime, value 1) over the uncompressed
format (value 0), but in the case of characteristic-2 fields prefers
the uncompressed format (value 0) over the compressed format
(ansiX962_compressed_char2, value 2), may indicate these preferences
by including an extension consisting of the following octets:
00 0B 00 04 03 01 00 02
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 26, line 30 skipping to change at page 25, line 30
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.
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-01 to draft-nir-tls-
rfc4492bis-03:
o Removed unused curves.
o Removed unused point formats (all but uncompressed)
Changes from draft-nir-tls-rfc4492bis-00 and draft-ietf-tls- Changes from draft-nir-tls-rfc4492bis-00 and draft-ietf-tls-
rfc4492bis-00 to draft-nir-tls-rfc4492bis-01: rfc4492bis-00 to draft-nir-tls-rfc4492bis-01:
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.
skipping to change at page 30, line 8 skipping to change at page 29, line 8
TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_NULL_SHA TLS_ECDH_RSA_WITH_NULL_SHA
TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Removed unused curves and all but the uncompressed point format.
Author's Address Author's Address
Yoav Nir Yoav Nir
Check Point Software Technologies Ltd. Check Point Software Technologies Ltd.
5 Hasolelim st. 5 Hasolelim st.
Tel Aviv 6789735 Tel Aviv 6789735
Israel Israel
Email: ynir.ietf@gmail.com Email: ynir.ietf@gmail.com
 End of changes. 19 change blocks. 
73 lines changed or deleted 61 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/