idnits 2.17.1 draft-ietf-tls-grease-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 (June 6, 2018) is 2149 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Benjamin 3 Internet-Draft Google 4 Intended status: Informational June 6, 2018 5 Expires: December 8, 2018 7 Applying GREASE to TLS Extensibility 8 draft-ietf-tls-grease-01 10 Abstract 12 This document describes GREASE (Generate Random Extensions And 13 Sustain Extensibility), a mechanism to prevent extensibility failures 14 in the TLS ecosystem. It reserves a set of TLS protocol values that 15 may be advertised to ensure peers correctly handle unknown values. 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 https://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 8, 2018. 34 Copyright Notice 36 Copyright (c) 2018 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 (https://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. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. GREASE Values . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Client-Initiated Extension Points . . . . . . . . . . . . . . 4 55 3.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 5 57 4. Server-Initiated Extension Points . . . . . . . . . . . . . . 6 58 4.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Client Behavior . . . . . . . . . . . . . . . . . . . . . 6 60 5. Sending GREASE Values . . . . . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 The TLS protocol [I-D.ietf-tls-tls13] includes several points of 70 extensibility, including the list of cipher suites and the list of 71 extensions. The values in these lists identify implementation 72 capabilities. TLS follows a model where one side, usually the 73 client, advertises capabilities and the peer, usually the server, 74 selects them. The responding side must ignore unknown values so that 75 new capabilities may be introduced to the ecosystem while maintaining 76 interoperability. 78 However, bugs may cause an implementation to reject unknown values. 79 It will interoperate with existing peers, so the mistake may spread 80 through the ecosystem unnoticed. Later, when new values are defined, 81 updated peers will discover that the metaphorical joint in the 82 protocol has rusted shut and that the new values cannot be deployed 83 without interoperability failures. 85 To avoid this problem, this document reserves some currently unused 86 values for TLS implementations to advertise at random. Correctly 87 implemented peers will ignore these values and interoperate. Peers 88 that do not tolerate unknown values will fail to interoperate, 89 revealing the mistake before it is widespread. 91 In keeping with the rusted joint metaphor, this technique is named 92 GREASE (Generate Random Extensions And Sustain Extensibility). 94 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 100 2. GREASE Values 102 This document reserves a number of TLS protocol values, referred to 103 as GREASE values. These values were allocated sparsely to discourage 104 server implementations from conditioning on them. For convenience, 105 they were also chosen so all types share a number scheme with a 106 consistent pattern while avoiding collisions with any existing 107 applicable registries in TLS. 109 The following values are reserved as GREASE values for cipher suites: 111 {TBD} {0x0A,0x0A} 112 {TBD} {0x1A,0x1A} 113 {TBD} {0x2A,0x2A} 114 {TBD} {0x3A,0x3A} 115 {TBD} {0x4A,0x4A} 116 {TBD} {0x5A,0x5A} 117 {TBD} {0x6A,0x6A} 118 {TBD} {0x7A,0x7A} 119 {TBD} {0x8A,0x8A} 120 {TBD} {0x9A,0x9A} 121 {TBD} {0xAA,0xAA} 122 {TBD} {0xBA,0xBA} 123 {TBD} {0xCA,0xCA} 124 {TBD} {0xDA,0xDA} 125 {TBD} {0xEA,0xEA} 126 {TBD} {0xFA,0xFA} 128 The following values are reserved as GREASE values for extensions, 129 named groups, signature algorithms, and versions: 131 {TBD} 0x0A0A 132 {TBD} 0x1A1A 133 {TBD} 0x2A2A 134 {TBD} 0x3A3A 135 {TBD} 0x4A4A 136 {TBD} 0x5A5A 137 {TBD} 0x6A6A 138 {TBD} 0x7A7A 139 {TBD} 0x8A8A 140 {TBD} 0x9A9A 141 {TBD} 0xAAAA 142 {TBD} 0xBABA 143 {TBD} 0xCACA 144 {TBD} 0xDADA 145 {TBD} 0xEAEA 146 {TBD} 0xFAFA 148 Future versions of TLS or DTLS [RFC6347] MUST NOT use any of the 149 above values as versions. 151 The following values are reserved as GREASE values for 152 PskKeyExchangeModes. 154 {TBD} 0x0B 155 {TBD} 0x2A 156 {TBD} 0x49 157 {TBD} 0x68 158 {TBD} 0x87 159 {TBD} 0xA6 160 {TBD} 0xC5 161 {TBD} 0xE4 163 Finally, this document reserves all ALPN identifiers [RFC7301] 164 beginning with the prefix "ignore/". This corresponds to the seven- 165 octet prefix: 0x69, 0x67, 0x6e, 0x6f, 0x72, 0x65, 0x2f. 167 3. Client-Initiated Extension Points 169 Most extension points in TLS are offered by the client and selected 170 by the server. This section details client and server behavior 171 around GREASE values for these. 173 3.1. Client Behavior 175 When sending a ClientHello, a client MAY behave as follows: 177 o A client MAY select one or more GREASE cipher suite values and 178 advertise them in the "cipher_suites" field. 180 o A client MAY select one or more GREASE extension values and 181 advertise corresponding extensions with varying length and 182 contents. 184 o A client MAY select one or more GREASE named group values and 185 advertise them in the "supported_groups" extension, if sent. It 186 MAY also send KeyShareEntry values for a subset of those selected 187 in the "key_share" extension. For each of these, the 188 "key_exchange" field MAY be any value. 190 o A client MAY select one or more GREASE signature algorithm values 191 and advertise them in the "signature_algorithms" extension, if 192 sent. 194 o A client MAY select one or more GREASE version values and 195 advertise them in the "supported_versions" extension, if sent. 197 o A client MAY select one or more GREASE PskKeyExchangeMode values 198 and advertise them in the "psk_key_exchange_modes" extension, if 199 sent. 201 o A client MAY select one or more GREASE ALPN identifiers and 202 advertise them in the "application_layer_protocol_negotiation" 203 extension, if sent. 205 Clients MUST reject GREASE values when negotiated by the server. 206 Specifically, the client MUST fail the connection if a GREASE value 207 appears any in the following: 209 o The "version" value in a ServerHello or HelloRetryRequest 211 o The "cipher_suite" value in a ServerHello 213 o Any ServerHello extension 215 o Any HelloRetryRequest, EncryptedExtensions, or Certificate 216 extension in TLS 1.3 218 o The "namedcurve" value in a ServerKeyExchange for an ECDHE cipher 219 in TLS 1.2 or earlier 221 o The signature algorithm in a ServerKeyExchange signature in TLS 222 1.2 or earlier 224 o The signature algorithm in a server CertificateVerify signature in 225 TLS 1.3 227 Note that this requires no special processing on the client. Clients 228 are already required to reject unknown values selected by the server. 230 3.2. Server Behavior 232 When processing a ClientHello, servers MUST NOT treat GREASE values 233 differently from any unknown value. Servers MUST NOT negotiate any 234 GREASE value when offered in a ClientHello. Servers MUST correctly 235 ignore unknown values in a ClientHello and attempt to negotiate with 236 one of the remaining parameters. 238 Note that these requirements are restatements or corollaries of 239 existing server requirements in TLS. 241 4. Server-Initiated Extension Points 243 Some extension points are offered by the server and selected by the 244 client. This section details client and server behavior around 245 GREASE values for these. 247 4.1. Server Behavior 249 When sending a CertificateRequest in TLS 1.3, a server MAY behave as 250 follows: 252 o A server MAY select one or more GREASE extension values and 253 advertise corresponding extensions with varying length and 254 contents. 256 o A server MAY select one or more GREASE signature algorithm values 257 and advertise them in the "signature_algorithms" extension. 259 When sending a NewSessionTicket message in TLS 1.3, a server MAY 260 select one or more GREASE extension values and advertise 261 corresponding extensions with varying length and contents. 263 Servers MUST reject GREASE values when negotiated by the client. 264 Specifically, the server MUST fail the connection if a GREASE value 265 appears any in the following: 267 o Any Certificate extension in TLS 1.3 269 o The signature algorithm in a client CertificateVerify signature 271 Note that this requires no special processing on the server. Servers 272 are already required to reject unknown values selected by the client. 274 4.2. Client Behavior 276 When processing a CertificateRequest or NewSessionTicket, clients 277 MUST NOT treat GREASE values differently from any unknown value. 278 Clients MUST NOT negotiate any GREASE value when offered by the 279 server. Clients MUST correctly ignore unknown values offered by the 280 server and attempt to negotiate with one of the remaining parameters. 282 Note that these requirements are restatements or corollaries of 283 existing client requirements in TLS. 285 5. Sending GREASE Values 287 Implementations advertising GREASE values SHOULD select them at 288 random. This is intended to encourage implementations to ignore all 289 unknown values rather than any individual value. Implementations 290 MUST honor protocol specifications when sending GREASE values. For 291 instance, implementations sending multiple GREASE values as 292 extensions MUST NOT send the same GREASE value twice. 294 Implementations SHOULD balance diversity in GREASE advertisements 295 with determinism. For example, a client which randomly varies GREASE 296 value positions for each connection may only fail against a broken 297 server with some probability. This risks the failure being masked by 298 automatic retries. A client which positions GREASE values 299 deterministically over a period of time (such as a single software 300 release) stresses fewer cases but is more likely to detect bugs from 301 those cases. 303 6. IANA Considerations 305 [[TODO: Update IANA considerations for TLS 1.3 and rebase over draft- 306 ietf-tls-iana-registry-updates.]] 308 This document updates the TLS Cipher Suite Registry, available from 309 : 311 +-------------------+-------------+---------+-----------------+ 312 | Value | Description | DTLS-OK | Reference | 313 +-------------------+-------------+---------+-----------------+ 314 | {TBD} {0x0A,0x0A} | Reserved | Y | (this document) | 315 | {TBD} {0x1A,0x1A} | Reserved | Y | (this document) | 316 | {TBD} {0x2A,0x2A} | Reserved | Y | (this document) | 317 | {TBD} {0x3A,0x3A} | Reserved | Y | (this document) | 318 | {TBD} {0x4A,0x4A} | Reserved | Y | (this document) | 319 | {TBD} {0x5A,0x5A} | Reserved | Y | (this document) | 320 | {TBD} {0x6A,0x6A} | Reserved | Y | (this document) | 321 | {TBD} {0x7A,0x7A} | Reserved | Y | (this document) | 322 | {TBD} {0x8A,0x8A} | Reserved | Y | (this document) | 323 | {TBD} {0x9A,0x9A} | Reserved | Y | (this document) | 324 | {TBD} {0xAA,0xAA} | Reserved | Y | (this document) | 325 | {TBD} {0xBA,0xBA} | Reserved | Y | (this document) | 326 | {TBD} {0xCA,0xCA} | Reserved | Y | (this document) | 327 | {TBD} {0xDA,0xDA} | Reserved | Y | (this document) | 328 | {TBD} {0xEA,0xEA} | Reserved | Y | (this document) | 329 | {TBD} {0xFA,0xFA} | Reserved | Y | (this document) | 330 +-------------------+-------------+---------+-----------------+ 332 Additions to the TLS Cipher Suite Registry 334 The cipher suite numbers listed in the first column are numbers used 335 for cipher suite interoperability testing and it's suggested that 336 IANA use these values for assignment. 338 This document updates the Supported Groups Registry, available from 339 : 341 +-------------+-------------+---------+-----------------+ 342 | Value | Description | DTLS-OK | Reference | 343 +-------------+-------------+---------+-----------------+ 344 | {TBD} 2570 | Reserved | Y | (this document) | 345 | {TBD} 6682 | Reserved | Y | (this document) | 346 | {TBD} 10794 | Reserved | Y | (this document) | 347 | {TBD} 14906 | Reserved | Y | (this document) | 348 | {TBD} 19018 | Reserved | Y | (this document) | 349 | {TBD} 23130 | Reserved | Y | (this document) | 350 | {TBD} 27242 | Reserved | Y | (this document) | 351 | {TBD} 31354 | Reserved | Y | (this document) | 352 | {TBD} 35466 | Reserved | Y | (this document) | 353 | {TBD} 39578 | Reserved | Y | (this document) | 354 | {TBD} 43690 | Reserved | Y | (this document) | 355 | {TBD} 47802 | Reserved | Y | (this document) | 356 | {TBD} 51914 | Reserved | Y | (this document) | 357 | {TBD} 56026 | Reserved | Y | (this document) | 358 | {TBD} 60138 | Reserved | Y | (this document) | 359 | {TBD} 64250 | Reserved | Y | (this document) | 360 +-------------+-------------+---------+-----------------+ 362 Additions to the Supported Groups Registry 364 The named group numbers listed in the first column are numbers used 365 for cipher suite interoperability testing and it's suggested that 366 IANA use these values for assignment. 368 This document updates the ExtensionType Values registry, available 369 from : 371 +-------------+----------------+-----------------+ 372 | Value | Extension name | Reference | 373 +-------------+----------------+-----------------+ 374 | {TBD} 2570 | Reserved | (this document) | 375 | {TBD} 6682 | Reserved | (this document) | 376 | {TBD} 10794 | Reserved | (this document) | 377 | {TBD} 14906 | Reserved | (this document) | 378 | {TBD} 19018 | Reserved | (this document) | 379 | {TBD} 23130 | Reserved | (this document) | 380 | {TBD} 27242 | Reserved | (this document) | 381 | {TBD} 31354 | Reserved | (this document) | 382 | {TBD} 35466 | Reserved | (this document) | 383 | {TBD} 39578 | Reserved | (this document) | 384 | {TBD} 43690 | Reserved | (this document) | 385 | {TBD} 47802 | Reserved | (this document) | 386 | {TBD} 51914 | Reserved | (this document) | 387 | {TBD} 56026 | Reserved | (this document) | 388 | {TBD} 60138 | Reserved | (this document) | 389 | {TBD} 64250 | Reserved | (this document) | 390 +-------------+----------------+-----------------+ 392 Additions to the ExtensionType Values registry 394 The extension numbers listed in the first column are numbers used for 395 cipher suite interoperability testing and it's suggested that IANA 396 use these values for assignment. 398 [[TODO: How do I write IANA instructions to reserve all ALPN 399 identifiers that begin with "ignore/"? Perhaps it would be better to 400 reserve a concrete handful of identifiers instead.]] 402 7. Security Considerations 404 GREASE values may not be negotiated, so they do not directly impact 405 the security of TLS connections. 407 Historically, when interoperability problems arise in deploying new 408 TLS features, implementations have used a fallback retry on error 409 with the feature disabled. This allows an active attacker to 410 silently disable the new feature. By preventing a class of such 411 interoperability problems, GREASE reduces the need for this kind of 412 fallback. 414 8. Acknowledgements 416 The author would like to thank Adam Langley, Nick Harper, and Steven 417 Valdez for their feedback and suggestions. In addition, the rusted 418 joint metaphor is originally due to Adam Langley. 420 9. Normative References 422 [I-D.ietf-tls-tls13] 423 Rescorla, E., "The Transport Layer Security (TLS) Protocol 424 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 425 March 2018. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, 430 . 432 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 433 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 434 January 2012, . 436 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 437 "Transport Layer Security (TLS) Application-Layer Protocol 438 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 439 July 2014, . 441 Author's Address 443 David Benjamin 444 Google 445 355 Main St 446 Cambridge, MA 02142 447 USA 449 Email: davidben@google.com