doc/protocol/draft-ietf-tls-ecc-new-mac-00.txt

   1
   2
   3
   4 Network Working Group                                        E. Rescorla
   5 Internet-Draft                                         Network Resonance
   6 Intended status:  Informational                           April 23, 2007
   7 Expires:  October 25, 2007
   8
   9
  10 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
  11                                   Mode
  12                    draft-ietf-tls-ecc-new-mac-00.txt
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37    This Internet-Draft will expire on October 25, 2007.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The IETF Trust (2007).
  42
  43 Abstract
  44
  45    RFC 4492 describes elliptic curve cipher suites for Transport Layer
  46    Security (TLS).  However, all those cipher suites use SHA-1 as their
  47    MAC algorithm.  This document describes eight new CipherSuites for
  48    TLS/DTLS which specify stronger digest algorithms.  Four use HMAC
  49    with SHA-256 or SHA-384 and four use AES in Galois Counter Mode
  50    (GCM).
  51
  52
  53
  54
  55 Rescorla                Expires October 25, 2007                [Page 1]
  56 \f
  57 Internet-Draft               TLS ECC New MAC                  April 2007
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63      1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
  64    2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
  65      2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
  66      2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
  67      2.3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 4
  68      2.4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . 5
  69      2.5.  Security Considerations . . . . . . . . . . . . . . . . . . 5
  70        2.5.1.  Downgrade Attack  . . . . . . . . . . . . . . . . . . . 5
  71        2.5.2.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . 5
  72        2.5.3.  Counter Reuse with GCM  . . . . . . . . . . . . . . . . 5
  73      2.6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 5
  74    3.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  75      3.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
  76      3.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
  77    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
  78    Intellectual Property and Copyright Statements  . . . . . . . . . . 8
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Rescorla                Expires October 25, 2007                [Page 2]
 112 \f
 113 Internet-Draft               TLS ECC New MAC                  April 2007
 114
 115
 116 1.  Introduction
 117
 118    RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
 119    suites for Transport Layer Security (TLS).  However, all of the RFC
 120    4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
 121    analytic work on SHA-1 [Wang05], the IETF is gradually moving away
 122    from SHA-1 and towards stronger hash algorithms.  This document
 123    specifies TLS ECC cipher suites which replace SHA-256 and SHA-384
 124    rather than SHA-1.
 125
 126    TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
 127    encryption with additional data (AEAD) cipher modes
 128    [I-D.mcgrew-auth-enc].  This document also specifies a set of ECC
 129    cipher suites using one such mode, Galois Counter Mode (GCM) [GCM].
 130    Another document [I-D.salowey-tls-rsa-aes-gcm], provides support for
 131    GCM with other key establishment methods.
 132
 133 1.1.  Conventions Used In This Document
 134
 135    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 136    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 137    document are to be interpreted as described in [RFC2119].
 138
 139
 140 2.  Cipher Suites
 141
 142    This document defines 8 new cipher suites to be added to TLS.  All
 143    use Elliptic Curve Cryptography for key exchange and digital
 144    signature, as defined in RFC 4492.
 145
 146 2.1.  HMAC-based Cipher Suites
 147
 148    The first four cipher suites use AES [AES] in CBC mode with an HMAC-
 149    based MAC:
 150
 151        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
 152        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
 153        CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
 154        CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
 155
 156    These four cipher suites are the same as the corresponding cipher
 157    suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
 158    TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
 159    TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
 160    TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
 161    algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
 162
 163
 164
 165
 166
 167 Rescorla                Expires October 25, 2007                [Page 3]
 168 \f
 169 Internet-Draft               TLS ECC New MAC                  April 2007
 170
 171
 172       Cipher Suite                                MAC          PRF
 173       ------------                                ---          ---
 174       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA-256
 175       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA-384
 176       TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA-256
 177       TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA-384
 178
 179 2.2.  Galois Counter Mode-based Cipher Suites
 180
 181    The second four cipher suites use the new authenticated encryption
 182    modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
 183
 184        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
 185        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
 186        CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
 187        CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
 188
 189    These cipher suites use the authenticated encryption with additional
 190    data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
 191    [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
 192    be 12 bytes long, and constructed as follows:
 193
 194              struct {
 195                 opaque salt[4];
 196                 uint64 seq_num;
 197              } GCMNonce.
 198
 199    The salt value is either the client_write_IV if the client is sending
 200    or the server_write_IV if the server is sending.  These IVs SHALL be
 201    4 bytes long.
 202
 203    In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
 204    48-bit seq_num.
 205
 206    The PRF algorithms SHALL be as follows:
 207
 208    For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
 209    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
 210
 211    For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
 212    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-384.
 213
 214 2.3.  Acknowledgements
 215
 216    This work was supported by the US Department of Defense.
 217
 218
 219
 220
 221
 222
 223 Rescorla                Expires October 25, 2007                [Page 4]
 224 \f
 225 Internet-Draft               TLS ECC New MAC                  April 2007
 226
 227
 228 2.4.  TLS Versions
 229
 230    Because these cipher suites depend on features available only in TLS
 231    1.2 (PRF flexibility and combined authenticated encryption cipher
 232    modes), they MUST NOT be negotiated in older versions of TLS.
 233    Clients MUST NOT offer these cipher suites if they do not offer TLS
 234    1.2 or later.  Servers which select an earlier version of TLS MUST
 235    NOT select one of these cipher suites.  Because TLS has no way for
 236    the client to indicate that it supports TLS 1.2 but not earlier, a
 237    non-compliant server might potentially negotiate TLS 1.1 or earlier
 238    and select one of the cipher suites in this document.  Clients MUST
 239    check the TLS version and generate a fatal "illegal_parameter" alert
 240    if they detect an incorrect version.
 241
 242 2.5.  Security Considerations
 243
 244    The security considerations in RFC 4346 and RFC 4492 apply to this
 245    document as well.  The remainder of this section describes security
 246    considerations specific to the cipher suites described in this
 247    document.
 248
 249 2.5.1.  Downgrade Attack
 250
 251    TLS negotiation is only as secure as the weakest cipher suite that is
 252    supported.  For instance, an implementation which supports both 160-
 253    bit and 256-bit elliptic curves can be subject to an active downgrade
 254    attack to the 160-bit security level.  An attacker who can attack
 255    that can then forge the Finished handshake check and successfully
 256    mount a man-in-the-middle attack.
 257
 258 2.5.2.  Perfect Forward Secrecy
 259
 260    The static ECDH cipher suites specified in this document do not
 261    provide perfect forward secrecy (PFS).  Thus, compromise of a single
 262    static key leads to potential decryption of all traffic protected
 263    using that key.  Implementors of this specification SHOULD provide at
 264    least one ECDHE mode of operation.
 265
 266 2.5.3.  Counter Reuse with GCM
 267
 268    AES-GCM is only secure if the counter is never reused.  The IV
 269    construction algorithm above is designed to ensure that that cannot
 270    happen.
 271
 272 2.6.  IANA Considerations
 273
 274    IANA has assigned the following values for these cipher suites:
 275
 276
 277
 278
 279 Rescorla                Expires October 25, 2007                [Page 5]
 280 \f
 281 Internet-Draft               TLS ECC New MAC                  April 2007
 282
 283
 284       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
 285       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
 286       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
 287       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
 288       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
 289       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
 290       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
 291       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
 292
 293
 294 3.  References
 295
 296 3.1.  Normative References
 297
 298    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 299               Requirement Levels", BCP 14, RFC 2119, March 1997.
 300
 301    [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
 302               Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
 303               for Transport Layer Security (TLS)", RFC 4492, May 2006.
 304
 305    [I-D.mcgrew-auth-enc]
 306               McGrew, D., "An Interface and Algorithms for Authenticated
 307               Encryption", draft-mcgrew-auth-enc-02 (work in progress),
 308               March 2007.
 309
 310    [I-D.ietf-tls-rfc4346-bis]
 311               Dierks, T. and E. Rescorla, "The TLS Protocol Version
 312               1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress),
 313               March 2007.
 314
 315    [AES]      National Institute of Standards and Technology,
 316               "Specification for the Advanced Encryption Standard
 317               (AES)", FIPS 197, November 2001.
 318
 319    [SHS]      National Institute of Standards and Technology, "Secure
 320               Hash Standard", FIPS 180-2, August 2002.
 321
 322    [GCM]      National Institute of Standards and Technology,
 323               "Recommendation for Block Cipher Modes of Operation:
 324               Galois;/Counter Mode (GCM) for Confidentiality and
 325               Authentication", SP 800-38D (DRAFT), April 2006.
 326
 327    [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
 328               Full SHA-1", CRYPTO 2005, August 2005.
 329
 330
 331
 332
 333
 334
 335 Rescorla                Expires October 25, 2007                [Page 6]
 336 \f
 337 Internet-Draft               TLS ECC New MAC                  April 2007
 338
 339
 340 3.2.  Informative References
 341
 342    [I-D.salowey-tls-rsa-aes-gcm]
 343               Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
 344               draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
 345               February 2007.
 346
 347
 348 Author's Address
 349
 350    Eric Rescorla
 351    Network Resonance
 352    2483 E. Bayshore #212
 353    Palo Alto  94303
 354    USA
 355
 356    Email:  ekr@networkresonance.com
 357
 358
 359
 360
 361
 362
 363
 364
 365
 366
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391 Rescorla                Expires October 25, 2007                [Page 7]
 392 \f
 393 Internet-Draft               TLS ECC New MAC                  April 2007
 394
 395
 396 Full Copyright Statement
 397
 398    Copyright (C) The IETF Trust (2007).
 399
 400    This document is subject to the rights, licenses and restrictions
 401    contained in BCP 78, and except as set forth therein, the authors
 402    retain all their rights.
 403
 404    This document and the information contained herein are provided on an
 405    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 406    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 407    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 408    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 409    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 410    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 411
 412
 413 Intellectual Property
 414
 415    The IETF takes no position regarding the validity or scope of any
 416    Intellectual Property Rights or other rights that might be claimed to
 417    pertain to the implementation or use of the technology described in
 418    this document or the extent to which any license under such rights
 419    might or might not be available; nor does it represent that it has
 420    made any independent effort to identify any such rights.  Information
 421    on the procedures with respect to rights in RFC documents can be
 422    found in BCP 78 and BCP 79.
 423
 424    Copies of IPR disclosures made to the IETF Secretariat and any
 425    assurances of licenses to be made available, or the result of an
 426    attempt made to obtain a general license or permission for the use of
 427    such proprietary rights by implementers or users of this
 428    specification can be obtained from the IETF on-line IPR repository at
 429    http://www.ietf.org/ipr.
 430
 431    The IETF invites any interested party to bring to its attention any
 432    copyrights, patents or patent applications, or other proprietary
 433    rights that may cover technology that may be required to implement
 434    this standard.  Please address the information to the IETF at
 435    ietf-ipr@ietf.org.
 436
 437
 438 Acknowledgment
 439
 440    Funding for the RFC Editor function is provided by the IETF
 441    Administrative Support Activity (IASA).
 442
 443
 444
 445
 446
 447 Rescorla                Expires October 25, 2007                [Page 8]
 448 \f
 449