[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-rescorla-tls-suiteb) 00 01 02 03 04 05 06 07 RFC 5289

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/