TLS Working Group P. Gutmann Internet-Draft University of Auckland Intended status: Standards Track April 24, 2011 Expires: October 26, 2011 Standardised ECC Cipher Suites for TLS draft-gutmann-tls-eccsuites-00.txt Abstract This document describes a set of standard ECC cipher suites for TLS that simplify the complex selection procedure described in the existing ECC RFC, simplifying implementation and easing interoperability problems. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 26, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gutmann Expires October 26, 2011 [Page 1] Internet-Draft ECC-Suites-for-TLS April 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3 2. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Gutmann Expires October 26, 2011 [Page 2] Internet-Draft ECC-Suites-for-TLS April 2011 1. Introduction [TLS-ECC] provides an extremely flexible, and by extension extremely complex means of specifying a large number of options involving the use of ECC algorithms for [TLS]. As such the "cipher suites" in [TLS-ECC] aren't suites in the conventional TLS sense but more an indication of intent to negotiate a Chinese menu, with details to be decided on later via various TLS extensions and parameter settings. This makes deciding on a particular suite nondeterministic, since later parameter choices and settings can negate the initial "cipher suite" choice, requiring returning to the suite list to try with another Chinese-menu suite in the hope that later parameter choices allow it to be used. In practice no deployed implementation actually does this, either dropping the connection or aborting the handshake with a handshake- failure if the expected parameters aren't present throughout the various locations in the TLS handshake in which ECC parameters can be specified. This means that establishing a TLS connection using ECC often requires trial-and-error probing to ascertain what the other side is expecting to see before a connection can be established. Experience with deployed implementations indicates that all of them appear to implement a common subset of fixed ECC parameters that work in all cases (alongside the more obscure options), representing a de facto profile of standard cipher suites rather than Chinese-menu selection options. This document standardises this de facto usage by defining a small number of standard ECC cipher suites with unambiguous parameters and settings. 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]. Gutmann Expires October 26, 2011 [Page 3] Internet-Draft ECC-Suites-for-TLS April 2011 2. Cipher Suites The table below defines standard ECC cipher suites with fixed, unambiguous parameters, based on the de facto profiles of suites seen in use in practice. Since the form of these suites match the existing non-ECC suites, they follow the existing suites in the { 0x00, 0xXX } range rather than being placed with the Chinese-menu- selection suites at { 0xC0, 0xXX }. CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_128_CBC_SHA = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_256_CBC_SHA = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_128_CBC_SHA = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_256_CBC_SHA = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_128_CBC_SHA256 = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_256_CBC_SHA256 = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_128_CBC_SHA384 = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_256_CBC_SHA384 = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_128_GCM_SHA256 = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_256_GCM_SHA256 = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_128_GCM_SHA384 = { 0x00, 0xXX } CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_256_GCM_SHA384 = { 0x00, 0xXX } [[[At least one major implementation, Microsoft's SChannel, already does this, see . For example it lists 'suites' like TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256. The above choices happen to coincide with the Microsoft ones not because of any explicit attempt to copy the Microsoft options but because they represent the obvious, logical choices]]]. For each cipher suite with their ECC parameters denoted 'P256' or 'P384', the ECC parameters are: o ECDH key agreement in Server Key Exchange/Client Key Exchange message: NIST P-256/X9.62 p256r1/SECG p256r1 or NIST P-384/SECG p384r1 curve with uncompressed points as indicated in the suite name. Gutmann Expires October 26, 2011 [Page 4] Internet-Draft ECC-Suites-for-TLS April 2011 o ECDSA signature in Server Key Exchange message: P256 or P384 curve as for ECDH with uncompressed points and SHA1, SHA256 or SHA384 as indicated in the suite name. o Client authentication in Certificate Request/Certificate Verify messages: SHA1, SHA256, or SHA384 as indicated in the suite name. If no additional Chinese-menu ECC suites are used, implementations SHOULD NOT send the Supported Elliptic Curves or Supported Point Formats extensions since these parameters are fully specified by the suite choice. If additional Chinese-menu suites are used, implementations MUST send the Supported Elliptic Curves and Supported Point Formats extensions as per [TLS-ECC]. The parameters specified in these extensions apply only to the Chinese-menu suites, not the fixed suites defined above. Note that the suites defined in this document augment, rather than supplant, the existing Chinese-menu suites options. Anyone requiring the use of more unusual ECC parameters and options can use the Chinese-menu capability to specify and select any parameters that they require. Gutmann Expires October 26, 2011 [Page 5] Internet-Draft ECC-Suites-for-TLS April 2011 3. Security Considerations This document is a profile of, and simplifcation of, [TLS-ECC]. No further security considerations are introduced beyond those present in [TLS-ECC] . Gutmann Expires October 26, 2011 [Page 6] Internet-Draft ECC-Suites-for-TLS April 2011 4. IANA Considerations This document defines new ciphers suites for TLS [to be allocated in the currently unallocated range { 0x00, 0xC6 } - { 0x00, 0xD1 }]. Gutmann Expires October 26, 2011 [Page 7] Internet-Draft ECC-Suites-for-TLS April 2011 5. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [TLS-ECC] Blake-Wilson, S., Bolyard, N., Gupta, V., and C. Hawk, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006. Gutmann Expires October 26, 2011 [Page 8] Internet-Draft ECC-Suites-for-TLS April 2011 Author's Address Peter Gutmann University of Auckland Department of Computer Science New Zealand Email: pgut001@cs.auckland.ac.nz Gutmann Expires October 26, 2011 [Page 9]