idnits 2.17.1 draft-gutmann-tls-eccsuites-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 10, 2011) is 4734 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4492 (ref. 'TLS-ECC') (Obsoleted by RFC 8422) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TLS Working Group P. Gutmann 2 Internet-Draft University of Auckland 3 Intended status: Standards Track May 10, 2011 4 Expires: November 11, 2011 6 Standardised ECC Cipher Suites for TLS 7 draft-gutmann-tls-eccsuites-01.txt 9 Abstract 11 This document describes a set of standard ECC cipher suites for TLS 12 that simplify the complex selection procedure described in the 13 existing ECC RFC, simplifying implementation and easing 14 interoperability problems. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 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." 31 This Internet-Draft will expire on November 11, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 52 2. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 5. Normative References . . . . . . . . . . . . . . . . . . . . . 9 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 1. Introduction 61 [TLS-ECC] provides an extremely flexible, and by extension extremely 62 complex means of specifying a large number of options involving the 63 use of ECC algorithms for [TLS]. As such the "cipher suites" in 64 [TLS-ECC] aren't suites in the conventional TLS sense but more an 65 indication of intent to negotiate a Chinese menu, with details to be 66 decided on later via various TLS extensions and parameter settings. 67 This makes deciding on a particular suite nondeterministic, since 68 later parameter choices and settings can negate the initial "cipher 69 suite" choice, requiring returning to the suite list to try with 70 another Chinese-menu suite in the hope that later parameter choices 71 allow it to be used. 73 In practice no deployed implementation actually does this, either 74 dropping the connection or aborting the handshake with a handshake- 75 failure if the expected parameters aren't present throughout the 76 various locations in the TLS handshake in which ECC parameters can be 77 specified. This means that establishing a TLS connection using ECC 78 often requires trial-and-error probing to ascertain what the other 79 side is expecting to see before a connection can be established. 81 Experience with deployed implementations indicates that all of them 82 appear to implement a common subset of fixed ECC parameters that work 83 in all cases (alongside the more obscure options), representing a de 84 facto profile of standard cipher suites rather than Chinese-menu 85 selection options. This document standardises this de facto usage by 86 defining a small number of standard ECC cipher suites with 87 unambiguous parameters and settings. 89 1.1. Conventions Used in This Document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Cipher Suites 97 The table below defines standard ECC cipher suites with fixed, 98 unambiguous parameters, based on the de facto profiles of suites seen 99 in use in practice. Since the form of these suites match the 100 existing non-ECC suites, they follow the existing suites in the { 101 0x00, 0xXX } range rather than being placed with the Chinese-menu 102 suites at { 0xC0, 0xXX }. 104 CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_128_CBC_SHA = { 0x00, 0xXX } 105 CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_256_CBC_SHA = { 0x00, 0xXX } 106 CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_128_CBC_SHA = { 0x00, 0xXX } 107 CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_256_CBC_SHA = { 0x00, 0xXX } 109 CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_128_CBC_SHA256 = 110 { 0x00, 0xXX } 111 CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_256_CBC_SHA256 = 112 { 0x00, 0xXX } 113 CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_128_CBC_SHA384 = 114 { 0x00, 0xXX } 115 CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_256_CBC_SHA384 = 116 { 0x00, 0xXX } 118 CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_128_GCM_SHA256 = 119 { 0x00, 0xXX } 120 CipherSuite TLS_ECDHE_ECDSA_P256_WITH_AES_256_GCM_SHA256 = 121 { 0x00, 0xXX } 122 CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_128_GCM_SHA384 = 123 { 0x00, 0xXX } 124 CipherSuite TLS_ECDHE_ECDSA_P384_WITH_AES_256_GCM_SHA384 = 125 { 0x00, 0xXX } 127 In the above lists, the first set of suites allows use with TLS 1.0 128 and 1.1, the second set allows use with TLS 1.2, and the third set 129 allows use with Suite B. 131 [[[At least one major implementation, Microsoft's SChannel, already 132 does this, see 133 . 134 For example it lists 'suites' like 135 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 and 136 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256. The above choices 137 happen to coincide with the Microsoft ones not because of any 138 explicit attempt to copy the Microsoft options but because they 139 represent the obvious, logical choices]]]. 141 For each cipher suite with their ECC parameters denoted 'P256' or 142 'P384', the ECC parameters are: 144 o ECDH key agreement in Server Key Exchange/Client Key Exchange 145 message: NIST P-256/X9.62 p256r1/SECG p256r1 or NIST P-384/SECG 146 p384r1 curve with uncompressed points as indicated in the suite 147 name. 148 o ECDSA signature in Server Key Exchange message: P256 or P384 curve 149 as for ECDH with uncompressed points and SHA1, SHA256 or SHA384 as 150 indicated in the suite name. 151 o Client authentication in Certificate Request/Certificate Verify 152 messages: SHA1, SHA256, or SHA384 as indicated in the suite name. 154 If no additional Chinese-menu ECC suites are used, implementations 155 SHOULD NOT send the Supported Elliptic Curves or Supported Point 156 Formats extensions since these parameters are fully specified by the 157 suite choice. If additional Chinese-menu suites are used, 158 implementations MUST send the Supported Elliptic Curves and Supported 159 Point Formats extensions as per [TLS-ECC]. The parameters specified 160 in these extensions apply only to the Chinese-menu suites, not the 161 fixed suites defined above. 163 [TLS] states that if the client does not send the 164 signature_algorithms extension then the hash algorithm defaults to 165 SHA1. This is required in order to provide a fall-back default if no 166 other means of specifying the hash algorithm to be used is available. 167 Since this document makes the use of the hash algorithm explicit in 168 the cipher suite, the fall- back to the SHA1 default is never 169 triggered. 171 Note that the suites defined in this document augment, rather than 172 supplant, the existing Chinese-menu suites options. Anyone requiring 173 the use of more unusual ECC parameters and options can use the 174 Chinese-menu capability to specify and select any parameters that 175 they require. 177 2.1. Discussion 179 The issue that this document is intended to address may be more 180 easily seen by considering how the parts of the Client Hello are 181 processed. For standard cipher suites the server iterates through a 182 list of suites proposed by the client and selects the most cromulent 183 one. For example a server may have a list of suite IDs and 184 parameters sorted in order of preference and select the lowest-ranked 185 suite in the list from the ones proposed by the client. 187 For the Chinese-menu suites on the other hand, the server sees a 188 Chinese menu selector sent by the client and then has to skip the 189 remaining suites and other parts of the hello and process the 190 extensions to see whether what's in there matches up with that the 191 Chinese-menu selector requested. For example if the Chinese menu 192 said TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 but the supported-curves 193 says P256 then the server has to either hope that the other side does 194 the special-case X9.62 handling for hash truncation and gets it right 195 (experience with current implementations indicates that they don't 196 even support this capability, let alone get it right), or not take 197 the gamble and go back to the cipher suites and look for another 198 Chinese-menu option, and then skip the rest of the hello and process 199 the extensions again to see if things work out this time, and if that 200 doesn't work either then go back ... 202 In practice with currently-deployed implementations it's hard enough 203 just trying to figure out which basic combinations of parameters they 204 support (the usual response is a dropped connection or aborted 205 handshake, requiring the use of trial-and-error probing to find out 206 what's possible), and even getting to the point of being able to 207 interop-test any of the more exotic combinations like hash truncation 208 becomes more or less impossible. So the purpose of this document is 209 to try and identify the common combinations of parameters that 210 everyone seems to implement anyway and list them as conventional 211 cipher suites, with no further parameterisation required. 213 An additional problem with the Chinese-menu selection process is the 214 fact that although it allows the specification of arbitrary numbers 215 of handshake parameters, it never nails down how and where these 216 parameters should be applied. Practical experience with 217 implementations indicates that only the most straightforward 218 combinations of algorithm parameters are likely to work. For example 219 although it's possible to specify both P256 and P384 as acceptable 220 curves, what this tends to mean in practice is that { ECDH P256 + 221 ECDSA P256 } or { ECDH P384 + ECDSA P384 } are acceptable but { ECDH 222 P256 + ECDSA P384 } or { ECDH P384 + ECDSA P256 } aren't. In the 223 interests of interoperability it's recommended that, despite the 224 apparent flexibility implied by the Chinese menu, implementations 225 stick to the most straightforward application of algorithm 226 parameters, using the same algorithm or parameters throughout the 227 handshake even if it's implied by the Chinese-menu that mix-and-match 228 combinations are possible. For example if the overall cipher suite 229 is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 then use SHA256 everywhere 230 a hash function is used; if the curve types are P256 or P384 then use 231 either P256 everywhere or P384 everywhere. This design principle is 232 captured in the requirements given in Section 2. 234 The term "Chinese menu" comes from the US, where Chinese restaurants 235 traditionally had columns for ordering food, and orders were put 236 together in a mix-and-match manner by ordering an item from column A, 237 two from column B, and so on. Any process that involves picking a 238 selection from different columns has become described as a "Chinese 239 menu system". 241 3. Security Considerations 243 This document is a profile of, and simplifcation of, [TLS-ECC]. No 244 further security considerations are introduced beyond those present 245 in [TLS-ECC] . 247 4. IANA Considerations 249 This document defines new cipher suites for TLS [to be allocated in 250 the currently unallocated range { 0x00, 0xC6 } - { 0x00, 0xD1 }]. 252 5. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 258 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 260 [TLS-ECC] Blake-Wilson, S., Bolyard, N., Gupta, V., and C. Hawk, 261 "Elliptic Curve Cryptography (ECC) Cipher Suites for 262 Transport Layer Security (TLS)", RFC 4492, May 2006. 264 Author's Address 266 Peter Gutmann 267 University of Auckland 268 Department of Computer Science 269 New Zealand 271 Email: pgut001@cs.auckland.ac.nz