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