Network Working Group E. Rescorla
Internet-Draft Network Resonance
Intended status: Informational June 2, 2007
Expires: December 4, 2007
TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
Mode
draft-ietf-tls-ecc-new-mac-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 4, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
RFC 4492 describes elliptic curve cipher suites for Transport Layer
Security (TLS). However, all those cipher suites use SHA-1 as their
MAC algorithm. This document describes eight new CipherSuites for
TLS/DTLS which specify stronger digest algorithms. Four use HMAC
with SHA-256 or SHA-384 and four use AES in Galois Counter Mode
(GCM).
Rescorla Expires December 4, 2007 [Page 1]
Internet-Draft TLS ECC New MAC June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used In This Document . . . . . . . . . . . . . 3
2. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. HMAC-based Cipher Suites . . . . . . . . . . . . . . . . . 3
2.2. Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
2.3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 5
2.4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Security Considerations . . . . . . . . . . . . . . . . . . 5
2.5.1. Downgrade Attack . . . . . . . . . . . . . . . . . . . 5
2.5.2. Perfect Forward Secrecy . . . . . . . . . . . . . . . . 6
2.5.3. Counter Reuse with GCM . . . . . . . . . . . . . . . . 6
2.6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Normative References . . . . . . . . . . . . . . . . . . . 6
3.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Rescorla Expires December 4, 2007 [Page 2]
Internet-Draft TLS ECC New MAC June 2007
1. Introduction
RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
suites for Transport Layer Security (TLS). However, all of the RFC
4492 suites use HMAC-SHA1 as their MAC algorithm. Due to recent
analytic work on SHA-1 [Wang05], the IETF is gradually moving away
from SHA-1 and towards stronger hash algorithms. This document
specifies TLS ECC cipher suites which replace SHA-256 and SHA-384
rather than SHA-1.
TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
encryption with additional data (AEAD) cipher modes
[I-D.mcgrew-auth-enc]. This document also specifies a set of ECC
cipher suites using one such mode, Galois Counter Mode (GCM) [GCM].
Another document [I-D.salowey-tls-rsa-aes-gcm], provides support for
GCM with other key establishment methods.
1.1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Cipher Suites
This document defines 8 new cipher suites to be added to TLS. All
use Elliptic Curve Cryptography for key exchange and digital
signature, as defined in RFC 4492.
2.1. HMAC-based Cipher Suites
The first four cipher suites use AES [AES] in CBC [CBC] mode with an
HMAC-based MAC:
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 = {0xXX,XX};
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 = {0xXX,XX};
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 = {0xXX,XX};
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 = {0xXX,XX};
These four cipher suites are the same as the corresponding cipher
suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
Rescorla Expires December 4, 2007 [Page 3]
Internet-Draft TLS ECC New MAC June 2007
Cipher Suite MAC PRF
------------ --- ---
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 HMAC-SHA-256 P_SHA-256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 HMAC-SHA-384 P_SHA-384
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 HMAC-SHA-256 P_SHA-256
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 HMAC-SHA-384 P_SHA-384
2.2. Galois Counter Mode-based Cipher Suites
The second four cipher suites use the new authenticated encryption
modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 = {0xXX,XX};
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 = {0xXX,XX};
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 = {0xXX,XX};
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 = {0xXX,XX};
These cipher suites use authenticated encryption with additional data
algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
[I-D.mcgrew-auth-enc]. The "nonce" input to the AEAD algorithm SHALL
be 12 bytes long, and is "partially implicit" (see Section 3.2.1 of
[I-D.mcgrew-auth-enc]) part of the nonce is generated as part of the
handshake process and is static for the entire session and part is
carried in each packet.
struct {
opaque salt[4];
opaque explicit_nonce_part[8];
} GCMNonce.
The salt value is either the client_write_IV if the client is sending
or the server_write_IV if the server is sending. These IVs SHALL be
4 bytes long.
The explicit_nonce_part is chosen by the sender and included in the
packet. Each value of the explicit_nonce_part MUST be distinct from
all other values, for any fixed key. Failure to meet this uniqueness
requirement can significantly degrade security. The
explicit_nonce_part is carried in the IV field of the
GenericAEADCipher structure. Therefore, for all the algorithms
defined in this section, SecurityParameters.iv_length=8.
In the case of TLS the counter MAY be the 64-bit sequence number. In
the case of Datagram TLS [RFC4347] [NOTE: there needs to be a new
DTLS draft for AEAD, this is a placeholder] the counter MAY be formed
from the concatenation of the 16-bit epoch with the 48-bit sequence
number.
Rescorla Expires December 4, 2007 [Page 4]
Internet-Draft TLS ECC New MAC June 2007
The PRF algorithms SHALL be as follows:
For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-384.
2.3. Acknowledgements
This work was supported by the US Department of Defense.
David McGrew contributed substantual sections of the GCM nonce text
as well as providing a review of this document.
2.4. TLS Versions
Because these cipher suites depend on features available only in TLS
1.2 (PRF flexibility and combined authenticated encryption cipher
modes), they MUST NOT be negotiated by older versions of TLS.
Clients MUST NOT offer these cipher suites if they do not offer TLS
1.2 or later. Servers which select an earlier version of TLS MUST
NOT select one of these cipher suites. Because TLS has no way for
the client to indicate that it supports TLS 1.2 but not earlier, a
non-compliant server might potentially negotiate TLS 1.1 or earlier
and select one of the cipher suites in this document. Clients MUST
check the TLS version and generate a fatal "illegal_parameter" alert
if they detect an incorrect version.
2.5. Security Considerations
The security considerations in RFC 4346 and RFC 4492 apply to this
document as well. The remainder of this section describes security
considerations specific to the cipher suites described in this
document.
2.5.1. Downgrade Attack
TLS negotiation is only as secure as the weakest cipher suite that is
supported. For instance, an implementation which supports both 160-
bit and 256-bit elliptic curves can be subject to an active downgrade
attack to the 160-bit security level. An attacker who can attack
that can then forge the Finished handshake check and successfully
mount a man-in-the-middle attack.
Rescorla Expires December 4, 2007 [Page 5]
Internet-Draft TLS ECC New MAC June 2007
2.5.2. Perfect Forward Secrecy
The static ECDH cipher suites specified in this document do not
provide perfect forward secrecy (PFS). Thus, compromise of a single
static key leads to potential decryption of all traffic protected
using that key. Implementors of this specification SHOULD provide at
least one ECDHE mode of operation.
2.5.3. Counter Reuse with GCM
AES-GCM is only secure if the counter is never reused. The IV
construction algorithm above is designed to ensure that this cannot
happen.
2.6. IANA Considerations
IANA has assigned the following values for these cipher suites:
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 = {0xXX,XX};
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 = {0xXX,XX};
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 = {0xXX,XX};
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 = {0xXX,XX};
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 = {0xXX,XX};
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 = {0xXX,XX};
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 = {0xXX,XX};
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 = {0xXX,XX};
3. References
3.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[I-D.mcgrew-auth-enc]
McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", draft-mcgrew-auth-enc-02 (work in progress),
March 2007.
[I-D.ietf-tls-rfc4346-bis]
Rescorla Expires December 4, 2007 [Page 6]
Internet-Draft TLS ECC New MAC June 2007
Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress),
March 2007.
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", FIPS 197, November 2001.
[SHS] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS 180-2, August 2002.
[CBC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation -
Methods and Techniques", SP 800-38A, December 2001.
[GCM] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation:
Galois;/Counter Mode (GCM) for Confidentiality and
Authentication", SP 800-38D (DRAFT), April 2006.
[Wang05] Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
Full SHA-1", CRYPTO 2005, August 2005.
3.2. Informative References
[I-D.salowey-tls-rsa-aes-gcm]
Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
February 2007.
Author's Address
Eric Rescorla
Network Resonance
2483 E. Bayshore #212
Palo Alto 94303
USA
Email: ekr@networkresonance.com
Rescorla Expires December 4, 2007 [Page 7]
Internet-Draft TLS ECC New MAC June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rescorla Expires December 4, 2007 [Page 8]
