< draft-ietf-tls-rfc4492bis-11.txt   draft-ietf-tls-rfc4492bis-12.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: July 15, 2017 M. Pegourie-Gonnard Expires: August 20, 2017 M. Pegourie-Gonnard
Independent / PolarSSL Independent / PolarSSL
January 11, 2017 February 16, 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-11 draft-ietf-tls-rfc4492bis-12
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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 15, 2017. This Internet-Draft will expire on August 20, 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 17, line 12 skipping to change at page 17, line 12
the contents of which are the DER encoding corresponding to the the contents of which are the DER encoding corresponding to the
following ASN.1 notation. following ASN.1 notation.
Ecdsa-Sig-Value ::= SEQUENCE { Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER, r INTEGER,
s INTEGER s INTEGER
} }
EdDSA signatures in both the protocol and in certificates that EdDSA signatures in both the protocol and in certificates that
conform to [PKIX-EdDSA] are generated and verified according to conform to [PKIX-EdDSA] are generated and verified according to
[CFRG-EdDSA]. The digitally-signed element is encoded as an opaque [RFC8032]. The digitally-signed element is encoded as an opaque
vector<0..2^16-1>, the contents of which is the octet string output vector<0..2^16-1>, the contents of which is the octet string output
of the EdDSA signing algorithm. of the EdDSA signing algorithm.
Actions of the sender: Actions of the sender:
The server selects elliptic curve domain parameters and an ephemeral The server selects elliptic curve domain parameters and an ephemeral
ECDH public key corresponding to these parameters according to the ECDH public key corresponding to these parameters according to the
ECKAS-DH1 scheme from IEEE 1363 [IEEE.P1363.1998]. It conveys this ECKAS-DH1 scheme from IEEE 1363 [IEEE.P1363.1998]. It conveys this
information to the client in the ServerKeyExchange message using the information to the client in the ServerKeyExchange message using the
format defined above. format defined above.
skipping to change at page 22, line 31 skipping to change at page 22, line 31
consists of a pair of integers, r and s. The digitally-signed consists of a pair of integers, r and s. The digitally-signed
element is encoded as an opaque vector <0..2^16-1>, the contents of element is encoded as an opaque vector <0..2^16-1>, the contents of
which are the DER encoding [CCITT.X690] corresponding to the which are the DER encoding [CCITT.X690] corresponding to the
following ASN.1 notation [CCITT.X680]. following ASN.1 notation [CCITT.X680].
Ecdsa-Sig-Value ::= SEQUENCE { Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER, r INTEGER,
s INTEGER s INTEGER
} }
EdDSA signatures are generated and verified according to EdDSA signatures are generated and verified according to [RFC8032].
[CFRG-EdDSA]. The digitally-signed element is encoded as an opaque The digitally-signed element is encoded as an opaque
vector<0..2^16-1>, the contents of which is the octet string output vector<0..2^16-1>, the contents of which is the octet string output
of the EdDSA signing algorithm. of the EdDSA signing algorithm.
Actions of the sender: Actions of the sender:
The client computes its signature over all handshake messages sent or The client computes its signature over all handshake messages sent or
received starting at client hello and up to but not including this received starting at client hello and up to but not including this
message. It uses the private key corresponding to its certified message. It uses the private key corresponding to its certified
public key to compute the signature, which is conveyed in the format public key to compute the signature, which is conveyed in the format
defined above. defined above.
skipping to change at page 23, line 12 skipping to change at page 23, line 12
message, and verifies the signature using the public key it received message, and verifies the signature using the public key it received
in the client's Certificate message. in the client's Certificate message.
5.9. Elliptic Curve Certificates 5.9. Elliptic Curve Certificates
X.509 certificates containing ECC public keys or signed using ECDSA X.509 certificates containing ECC public keys or signed using ECDSA
MUST comply with [RFC3279] or another RFC that replaces or extends MUST comply with [RFC3279] or another RFC that replaces or extends
it. X.509 certificates containing ECC public keys or signed using it. X.509 certificates containing ECC public keys or signed using
EdDSA MUST comply with [PKIX-EdDSA]. Clients SHOULD use the elliptic EdDSA MUST comply with [PKIX-EdDSA]. Clients SHOULD use the elliptic
curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and
SEC 2 [SECG-SEC2] or in [CFRG-EdDSA]. SEC 2 [SECG-SEC2] or in [RFC8032].
EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the
eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the eddsa_ed25519 curve, and Ed448 and Ed448ph keys MUST use the
eddsa_ed448 curve. Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and eddsa_ed448 curve. Curves ecdh_x25519, ecdh_x448, eddsa_ed25519 and
eddsa_ed448 MUST NOT be used for ECDSA. eddsa_ed448 MUST NOT be used for ECDSA.
5.10. ECDH, ECDSA, and RSA Computations 5.10. ECDH, ECDSA, and RSA Computations
All ECDH calculations for the NIST curves (including parameter and All ECDH calculations for the NIST curves (including parameter and
key generation as well as the shared secret calculation) are key generation as well as the shared secret calculation) are
skipping to change at page 24, line 13 skipping to change at page 24, line 13
used. used.
All ECDSA computations MUST be performed according to ANSI X9.62 or All ECDSA computations MUST be performed according to ANSI X9.62 or
its successors. Data to be signed/verified is hashed, and the result its successors. Data to be signed/verified is hashed, and the result
run directly through the ECDSA algorithm with no additional hashing. run directly through the ECDSA algorithm with no additional hashing.
The default hash function is SHA-1 [FIPS.180-2], and sha_size (see The default hash function is SHA-1 [FIPS.180-2], and sha_size (see
Section 5.4 and Section 5.8) is 20. However, an alternative hash Section 5.4 and Section 5.8) is 20. However, an alternative hash
function, such as one of the new SHA hash functions specified in FIPS function, such as one of the new SHA hash functions specified in FIPS
180-2 [FIPS.180-2], SHOULD be used instead. 180-2 [FIPS.180-2], SHOULD be used instead.
All EdDSA computations MUST be performed according to [CFRG-EdDSA] or All EdDSA computations MUST be performed according to [RFC8032] or
its succesors. Data to be signed/verified is run through the EdDSA its succesors. Data to be signed/verified is run through the EdDSA
algorithm wih no hashing (EdDSA will internally run the data through algorithm wih no hashing (EdDSA will internally run the data through
the PH function). the PH function). The context parameter for Ed448 MUST be set to the
empty string.
RFC 4492 anticipated the standardization of a mechanism for RFC 4492 anticipated the standardization of a mechanism for
specifying the required hash function in the certificate, perhaps in specifying the required hash function in the certificate, perhaps in
the parameters field of the subjectPublicKeyInfo. Such the parameters field of the subjectPublicKeyInfo. Such
standardization never took place, and as a result, SHA-1 is used in standardization never took place, and as a result, SHA-1 is used in
TLS 1.1 and earlier (except for EdDSA, which uses identity function). TLS 1.1 and earlier (except for EdDSA, which uses identity function).
TLS 1.2 added a SignatureAndHashAlgorithm parameter to the TLS 1.2 added a SignatureAndHashAlgorithm parameter to the
DigitallySigned struct, thus allowing agility in choosing the DigitallySigned struct, thus allowing agility in choosing the
signature hash. EdDSA signatures MUST have HashAlgorithm of TBD5 signature hash. EdDSA signatures MUST have HashAlgorithm of TBD5
(Intrinsic). (Intrinsic).
skipping to change at page 26, line 39 skipping to change at page 26, line 41
Beyond elliptic curve size, the main issue is elliptic curve Beyond elliptic curve size, the main issue is elliptic curve
structure. As a general principle, it is more conservative to use structure. As a general principle, it is more conservative to use
elliptic curves with as little algebraic structure as possible. elliptic curves with as little algebraic structure as possible.
Thus, random curves are more conservative than special curves such as Thus, random curves are more conservative than special curves such as
Koblitz curves, and curves over F_p with p random are more Koblitz curves, and curves over F_p with p random are more
conservative than curves over F_p with p of a special form, and conservative than curves over F_p with p of a special form, and
curves over F_p with p random are considered more conservative than curves over F_p with p random are considered more conservative than
curves over F_2^m as there is no choice between multiple fields of curves over F_2^m as there is no choice between multiple fields of
similar size for characteristic 2. similar size for characteristic 2.
NEED TO ADD A PARAGRAPH HERE ABOUT WHY X25519/X448 ARE PREFERRABLE TO
NIST CURVES.
Another issue is the potential for catastrophic failures when a Another issue is the potential for catastrophic failures when a
single elliptic curve is widely used. In this case, an attack on the single elliptic curve is widely used. In this case, an attack on the
elliptic curve might result in the compromise of a large number of elliptic curve might result in the compromise of a large number of
keys. Again, this concern may need to be balanced against efficiency keys. Again, this concern may need to be balanced against efficiency
and interoperability improvements associated with widely-used curves. and interoperability improvements associated with widely-used curves.
Substantial additional information on elliptic curve choice can be Substantial additional information on elliptic curve choice can be
found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]. found in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4].
The Introduction of [RFC8032] lists the security, performance, and
operational advantages of EdDSA signatures over ECDSA signatures
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 8. 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
skipping to change at page 29, line 12 skipping to change at page 29, line 12
Specification of basic notation", CCITT Recommendation Specification of basic notation", CCITT Recommendation
X.680, July 2002. X.680, July 2002.
[CCITT.X690] [CCITT.X690]
International Telephone and Telegraph Consultative International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002. X.690, July 2002.
[CFRG-EdDSA]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08
(work in progress), August 2016.
[FIPS.186-4] [FIPS.186-4]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186-4, 2013, Signature Standard", FIPS PUB 186-4, 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/ <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[PKCS1] RSA Laboratories, "RSA Encryption Standard, Version 1.5", [PKCS1] RSA Laboratories, "RSA Encryption Standard, Version 1.5",
PKCS 1, November 1993. PKCS 1, November 1993.
[PKIX-EdDSA] [PKIX-EdDSA]
skipping to change at page 30, line 8 skipping to change at page 30, line 5
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006. Extensions", RFC 4366, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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
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 11.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/
 End of changes. 13 change blocks. 
18 lines changed or deleted 18 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/