idnits 2.17.1 draft-gutmann-tls-eccsuites-06.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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 10, 2014) is 3608 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. '2') (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4492 (ref. '3') (Obsoleted by RFC 8422) ** Downref: Normative reference to an Informational RFC: RFC 7027 (ref. '4') Summary: 4 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 June 10, 2014 4 Expires: December 12, 2014 6 Standardised ECC Cipher Suites for TLS 7 draft-gutmann-tls-eccsuites-06.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 December 12, 2014. 33 Copyright Notice 35 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 52 2. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 5 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 58 5.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 TLS-ECC [3] provides an extremely flexible, and by extension 64 extremely complex means of specifying a large number of options 65 involving the use of ECC algorithms for TLS [2]. As such the "cipher 66 suites" in TLS-ECC [3] and by extension TLS-ECC-Brainpool [4] aren't 67 suites in the conventional TLS sense but more an indication of intent 68 to negotiate a Chinese menu, with details to be decided on later via 69 various TLS extensions and parameter settings. This makes deciding 70 on a particular suite nondeterministic, since later parameter choices 71 and settings can negate the initial "cipher suite" choice, requiring 72 returning to the suite list to try with another Chinese-menu suite in 73 the hope that later parameter choices allow it to be used. 75 In practice no currently deployed implementation actually does this, 76 either dropping the connection or aborting the handshake with a 77 handshake-failure if the expected parameters aren't present 78 throughout the various locations in the TLS handshake in which ECC 79 parameters can be specified. This means that establishing a TLS 80 connection using ECC often requires trial-and-error probing to 81 ascertain what the other side is expecting to see before a connection 82 can be established. 84 Experience with deployed implementations indicates that all of them 85 appear to implement a common subset of fixed ECC parameters that work 86 in all cases (alongside the more obscure options), representing a de 87 facto profile of standard cipher suites rather than Chinese-menu 88 selection options. For example one widely-used implementation didn't 89 send out TLS ECC extensions and yet other implementations had no 90 problems interoperating with it, indicating that what this document 91 specifies is already a de facto profile of implementations. This 92 document standardises this de facto usage by defining a small number 93 of standard ECC cipher suites with unambiguous parameters and 94 settings. 96 1.1. Conventions Used in This Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [1]. 102 2. Cipher Suites 104 The table below defines standard ECC cipher suites with fixed, 105 unambiguous parameters, based on the de facto profiles of suites seen 106 in use in practice. Since the form of these suites match the 107 existing non-ECC suites, they follow the existing suites in the { 108 0x00, 0xXX } range rather than being placed with the Chinese-menu 109 suites at { 0xC0, 0xXX }. 111 CipherSuite TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_128_CBC_SHA = { 0x00, 0xXX } 112 CipherSuite TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_256_CBC_SHA = { 0x00, 0xXX } 113 CipherSuite TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_128_CBC_SHA = { 0x00, 0xXX } 114 CipherSuite TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_256_CBC_SHA = { 0x00, 0xXX } 115 CipherSuite TLS_ECDHE_ECDSA_BRAINPOOLP256_SHA256_WITH_AES_128_CBC_SHA = 116 { 0x00, 0xXX } 117 CipherSuite TLS_ECDHE_ECDSA_BRAINPOOLP256_SHA256_WITH_AES_256_CBC_SHA = 118 { 0x00, 0xXX } 119 CipherSuite TLS_ECDHE_ECDSA_BRAINPOOLP384_SHA384_WITH_AES_128_CBC_SHA = 120 { 0x00, 0xXX } 121 CipherSuite TLS_ECDHE_ECDSA_BRAINPOOLP384_SHA384_WITH_AES_256_CBC_SHA = 122 { 0x00, 0xXX } 124 CipherSuite TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_128_CBC_SHA256 = 125 { 0x00, 0xXX } 126 CipherSuite TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_256_CBC_SHA256 = 127 { 0x00, 0xXX } 128 CipherSuite TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_128_CBC_SHA384 = 129 { 0x00, 0xXX } 130 CipherSuite TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_256_CBC_SHA384 = 131 { 0x00, 0xXX } 132 CipherSuite TLS_ECDHE_ECDSA_BRAINPOOLP256_SHA256_WITH_AES_128_CBC_SHA256 = 133 { 0x00, 0xXX } 134 CipherSuite TLS_ECDHE_ECDSA_BRAINPOOLP256_SHA256_WITH_AES_256_CBC_SHA256 = 135 { 0x00, 0xXX } 136 CipherSuite TLS_ECDHE_ECDSA_BRAINPOOLP384_SHA384_WITH_AES_128_CBC_SHA384 = 137 { 0x00, 0xXX } 138 CipherSuite TLS_ECDHE_ECDSA_BRAINPOOLP384_SHA384_WITH_AES_256_CBC_SHA384 = 139 { 0x00, 0xXX } 141 CipherSuite TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_128_GCM_SHA256 = 142 { 0x00, 0xXX } 143 CipherSuite TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_256_GCM_SHA256 = 144 { 0x00, 0xXX } 145 CipherSuite TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_128_GCM_SHA384 = 146 { 0x00, 0xXX } 147 CipherSuite TLS_ECDHE_ECDSA_P384_SHA384_WITH_AES_256_GCM_SHA384 = 148 { 0x00, 0xXX } 150 In the above lists, the first set of suites allows use with TLS 1.0 151 and 1.1, the second set allows use with TLS 1.2, and the third set 152 allows use with Suite B. 154 For each cipher suite with their ECC parameters denoted 'P256', 155 'P384', 'Brainpool256' or 'Brainpool384' the ECC parameters are: 157 o ECDH key agreement in Server Key Exchange/Client Key Exchange 158 message: NIST P-256/X9.62 p256r1/SECG p256r1, NIST P-384/SECG 159 p384r1, Brainpool P256r1 or Brainpool P384r1 curve with 160 uncompressed points as indicated in the suite name. 161 o ECDSA signature in Server Key Exchange message: P256, P384, 162 BrainpoolP256 or BrainpoolP384 curve as for ECDH with uncompressed 163 points and SHA256 or SHA384 as indicated in the suite name. 164 o Client authentication in Certificate Request/Certificate Verify 165 messages: SHA256 or SHA384 as indicated in the suite name. 166 o (For the non-ECC parameters, namely the symmetric cipher, PRF, and 167 MAC: AES, SHA-1, SHA256, and SHA384 as indicated in the suite 168 name). 170 If no additional Chinese-menu ECC suites are used, implementations 171 SHOULD NOT send the Supported Elliptic Curves or Supported Point 172 Formats extensions since these parameters are fully specified by the 173 suite choice. If additional Chinese-menu suites are used, 174 implementations MUST send the Supported Elliptic Curves and Supported 175 Point Formats extensions as per TLS-ECC [3]. The parameters 176 specified in these extensions apply only to the Chinese-menu suites, 177 not the fixed suites defined above. 179 TLS [2] states that if the client doesn't send the 180 signature_algorithms extension then the hash algorithm defaults to 181 SHA1. This is required in order to provide a fall-back default if no 182 other means of specifying the hash algorithm to be used is available. 183 Since this document makes the use of the hash algorithm explicit in 184 the cipher suite, the fall-back to the SHA1 default SHOULD NOT be 185 triggered. 187 Note that the suites defined in this document augment, rather than 188 supplant, the existing Chinese-menu suites options. Anyone requiring 189 the use of more unusual ECC parameters and options can use the 190 Chinese-menu capability to specify and select any parameters that 191 they require. 193 2.1. Discussion 195 The issue that this document is intended to address may be more 196 easily seen by considering how the parts of the Client Hello are 197 processed. For standard cipher suites the server iterates through a 198 list of suites proposed by the client and selects the most cromulent 199 one. For example a server may have a list of suite IDs and 200 parameters sorted in order of preference and select the lowest-ranked 201 suite in the list from the ones proposed by the client. 203 For the Chinese-menu suites on the other hand, the server sees a 204 Chinese menu selector sent by the client and then has to skip the 205 remaining suites and other parts of the hello and process the 206 extensions to see whether what's in there matches up with that the 207 Chinese-menu selector requested. For example if the Chinese menu 208 said TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 but the supported-curves 209 extension says P256 then the server has to either hope that the other 210 side does the special-case X9.62 handling for hash truncation and 211 gets it right (experience with current implementations indicates that 212 they don't even support this capability, let alone get it right), or 213 not take the gamble and go back to the cipher suites and look for 214 another Chinese-menu option, and then skip the rest of the hello and 215 process the extensions again to see if things work out this time, and 216 if that doesn't work either then go back ... 218 In practice with currently-deployed implementations it's hard enough 219 just trying to figure out which basic combinations of parameters they 220 support (the usual response is a dropped connection or aborted 221 handshake, requiring the use of trial-and-error probing to find out 222 what's possible), and even getting to the point of being able to 223 interopability-test any of the more exotic combinations like hash 224 truncation becomes more or less impossible. So the purpose of this 225 document is to try and identify the common combinations of parameters 226 that everyone seems to implement anyway and list them as conventional 227 cipher suites, with no further parameterisation required. 229 At least one major implementation, Microsoft's SChannel, already does 230 this, listing 'suites' like 231 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 and 232 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256, see [1]. The choices 233 given in Section 2 coincide with the Microsoft ones not because of 234 any explicit attempt to copy them but because they represent the 235 obvious, logical choices. 237 An additional problem with the Chinese-menu selection process is the 238 fact that although it allows the specification of arbitrary numbers 239 of handshake parameters, it never nails down how and where these 240 parameters should be applied. Practical experience with 241 implementations indicates that only the most straightforward 242 combinations of algorithm parameters are likely to work. For example 243 although it's possible to specify both P256 and P384 as acceptable 244 curves, what this tends to mean in practice is that { ECDH P256 + 245 ECDSA P256 } or { ECDH P384 + ECDSA P384 } are acceptable but { ECDH 246 P256 + ECDSA P384 } or { ECDH P384 + ECDSA P256 } aren't. In the 247 interests of interoperability it's recommended that, despite the 248 apparent flexibility implied by the Chinese menu, implementations 249 stick to the most straightforward application of algorithm 250 parameters, using the same algorithm or parameters throughout the 251 handshake even if it's implied by the Chinese-menu that mix-and-match 252 combinations are possible. For example if the overall cipher suite 253 is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 then use SHA256 everywhere 254 a hash function is used; if the curve types are P256 or P384 then use 255 either P256 everywhere or P384 everywhere. This design principle is 256 captured in the requirements given in Section 2. 258 The term "Chinese menu" comes from the US (although the same usage, 259 going back at least half a century, exists in the UK as well), where 260 Chinese restaurants traditionally had columns for ordering food, and 261 orders were put together in a mix-and-match manner by ordering an 262 item from column A, two from column B, and so on. Any process that 263 involves picking a selection from different columns has become 264 described as a "Chinese menu system". 266 3. Security Considerations 268 This document is a profile of, and simplifcation of, TLS-ECC [3]. No 269 further security considerations are introduced beyond those present 270 in TLS-ECC [3]. 272 4. IANA Considerations 274 This document defines new cipher suites for TLS [to be allocated in 275 the currently unallocated range { 0x00, 0xC6 } - { 0x00, 0xD1 }]. 277 5. References 279 5.1. Normative References 281 [1] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [2] Dierks, T. and E. Rescorla, "The Transport Layer Security 285 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 287 [3] Blake-Wilson, S., Bolyard, N., Gupta, V., and C. Hawk, 288 "Elliptic Curve Cryptography (ECC) Cipher Suites for 289 Transport Layer Security (TLS)", RFC 4492, May 2006. 291 [4] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography 292 (ECC) Brainpool Curves for Transport Layer Security 293 (TLS)", RFC 7027, October 2013. 295 5.2. URIs 297 [1] http://msdn.microsoft.com/en-us/library/ 298 aa374757%28v=vs.85%29.aspx 300 Author's Address 302 Peter Gutmann 303 University of Auckland 304 Department of Computer Science 305 University of Auckland 306 New Zealand 308 Email: pgut001@cs.auckland.ac.nz