idnits 2.17.1 draft-ietf-tls-grease-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 16, 2019) is 1899 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 (~~), 2 warnings (==), 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 January 16, 2019 5 Expires: July 20, 2019 7 Applying GREASE to TLS Extensibility 8 draft-ietf-tls-grease-02 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 July 20, 2019. 34 Copyright Notice 36 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 10 63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 64 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 The TLS protocol [RFC8446] includes several points of extensibility, 70 including the list of cipher suites and the list of extensions. The 71 values in these lists identify implementation capabilities. TLS 72 follows a model where one side, usually the client, advertises 73 capabilities and the peer, usually the server, selects them. The 74 responding side must ignore unknown values so that new capabilities 75 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", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 RFC 2119 [RFC2119][RFC2119] RFC 8174 [RFC8174] when, and only 100 when, they appear in all capitals, as shown here. 102 2. GREASE Values 104 This document reserves a number of TLS protocol values, referred to 105 as GREASE values. These values were allocated sparsely to discourage 106 server implementations from conditioning on them. For convenience, 107 they were also chosen so all types share a number scheme with a 108 consistent pattern while avoiding collisions with any existing 109 applicable registries in TLS. 111 The following values are reserved as GREASE values for cipher suites 112 and ALPN [RFC7301] identifiers: 114 {TBD} {0x0A,0x0A} 115 {TBD} {0x1A,0x1A} 116 {TBD} {0x2A,0x2A} 117 {TBD} {0x3A,0x3A} 118 {TBD} {0x4A,0x4A} 119 {TBD} {0x5A,0x5A} 120 {TBD} {0x6A,0x6A} 121 {TBD} {0x7A,0x7A} 122 {TBD} {0x8A,0x8A} 123 {TBD} {0x9A,0x9A} 124 {TBD} {0xAA,0xAA} 125 {TBD} {0xBA,0xBA} 126 {TBD} {0xCA,0xCA} 127 {TBD} {0xDA,0xDA} 128 {TBD} {0xEA,0xEA} 129 {TBD} {0xFA,0xFA} 131 The following values are reserved as GREASE values for extensions, 132 named groups, signature algorithms, and versions: 134 {TBD} 0x0A0A 135 {TBD} 0x1A1A 136 {TBD} 0x2A2A 137 {TBD} 0x3A3A 138 {TBD} 0x4A4A 139 {TBD} 0x5A5A 140 {TBD} 0x6A6A 141 {TBD} 0x7A7A 142 {TBD} 0x8A8A 143 {TBD} 0x9A9A 144 {TBD} 0xAAAA 145 {TBD} 0xBABA 146 {TBD} 0xCACA 147 {TBD} 0xDADA 148 {TBD} 0xEAEA 149 {TBD} 0xFAFA 151 Future versions of TLS or DTLS [RFC6347] MUST NOT use any of the 152 above values as versions. 154 The following values are reserved as GREASE values for 155 PskKeyExchangeModes. 157 {TBD} 0x0B 158 {TBD} 0x2A 159 {TBD} 0x49 160 {TBD} 0x68 161 {TBD} 0x87 162 {TBD} 0xA6 163 {TBD} 0xC5 164 {TBD} 0xE4 166 3. Client-Initiated Extension Points 168 Most extension points in TLS are offered by the client and selected 169 by the server. This section details client and server behavior 170 around GREASE values for these. 172 3.1. Client Behavior 174 When sending a ClientHello, a client MAY behave as follows: 176 o A client MAY select one or more GREASE cipher suite values and 177 advertise them in the "cipher_suites" field. 179 o A client MAY select one or more GREASE extension values and 180 advertise corresponding extensions with varying length and 181 contents. 183 o A client MAY select one or more GREASE named group values and 184 advertise them in the "supported_groups" extension, if sent. It 185 MAY also send KeyShareEntry values for a subset of those selected 186 in the "key_share" extension. For each of these, the 187 "key_exchange" field MAY be any value. 189 o A client MAY select one or more GREASE signature algorithm values 190 and advertise them in the "signature_algorithms" extension, if 191 sent. 193 o A client MAY select one or more GREASE version values and 194 advertise them in the "supported_versions" extension, if sent. 196 o A client MAY select one or more GREASE PskKeyExchangeMode values 197 and advertise them in the "psk_key_exchange_modes" extension, if 198 sent. 200 o A client MAY select one or more GREASE ALPN identifiers and 201 advertise them in the "application_layer_protocol_negotiation" 202 extension, if sent. 204 Clients MUST reject GREASE values when negotiated by the server. 205 Specifically, the client MUST fail the connection if a GREASE value 206 appears any in the following: 208 o The "version" value in a ServerHello or HelloRetryRequest 210 o The "cipher_suite" value in a ServerHello 212 o Any ServerHello extension 214 o Any HelloRetryRequest, EncryptedExtensions, or Certificate 215 extension in TLS 1.3 217 o The "namedcurve" value in a ServerKeyExchange for an ECDHE cipher 218 in TLS 1.2 or earlier 220 o The signature algorithm in a ServerKeyExchange signature in TLS 221 1.2 or earlier 223 o The signature algorithm in a server CertificateVerify signature in 224 TLS 1.3 226 Note that this requires no special processing on the client. Clients 227 are already required to reject unknown values selected by the server. 229 3.2. Server Behavior 231 When processing a ClientHello, servers MUST NOT treat GREASE values 232 differently from any unknown value. Servers MUST NOT negotiate any 233 GREASE value when offered in a ClientHello. Servers MUST correctly 234 ignore unknown values in a ClientHello and attempt to negotiate with 235 one of the remaining parameters. 237 Note that these requirements are restatements or corollaries of 238 existing server requirements in TLS. 240 4. Server-Initiated Extension Points 242 Some extension points are offered by the server and selected by the 243 client. This section details client and server behavior around 244 GREASE values for these. 246 4.1. Server Behavior 248 When sending a CertificateRequest in TLS 1.3, a server MAY behave as 249 follows: 251 o A server MAY select one or more GREASE extension values and 252 advertise corresponding extensions with varying length and 253 contents. 255 o A server MAY select one or more GREASE signature algorithm values 256 and advertise them in the "signature_algorithms" extension. 258 When sending a NewSessionTicket message in TLS 1.3, a server MAY 259 select one or more GREASE extension values and advertise 260 corresponding extensions with varying length and contents. 262 Servers MUST reject GREASE values when negotiated by the client. 263 Specifically, the server MUST fail the connection if a GREASE value 264 appears any in the following: 266 o Any Certificate extension in TLS 1.3 268 o The signature algorithm in a client CertificateVerify signature 270 Note that this requires no special processing on the server. Servers 271 are already required to reject unknown values selected by the client. 273 4.2. Client Behavior 275 When processing a CertificateRequest or NewSessionTicket, clients 276 MUST NOT treat GREASE values differently from any unknown value. 277 Clients MUST NOT negotiate any GREASE value when offered by the 278 server. Clients MUST correctly ignore unknown values offered by the 279 server and attempt to negotiate with one of the remaining parameters. 281 Note that these requirements are restatements or corollaries of 282 existing client requirements in TLS. 284 5. Sending GREASE Values 286 Implementations advertising GREASE values SHOULD select them at 287 random. This is intended to encourage implementations to ignore all 288 unknown values rather than any individual value. Implementations 289 MUST honor protocol specifications when sending GREASE values. For 290 instance, implementations sending multiple GREASE values as 291 extensions MUST NOT send the same GREASE value twice. 293 Implementations SHOULD balance diversity in GREASE advertisements 294 with determinism. For example, a client which randomly varies GREASE 295 value positions for each connection may only fail against a broken 296 server with some probability. This risks the failure being masked by 297 automatic retries. A client which positions GREASE values 298 deterministically over a period of time (such as a single software 299 release) stresses fewer cases but is more likely to detect bugs from 300 those cases. 302 6. IANA Considerations 304 [[TODO: Update IANA considerations for TLS 1.3 and rebase over draft- 305 ietf-tls-iana-registry-updates.]] 307 This document updates the TLS Cipher Suite Registry, available from 308 : 310 +-------------------+-------------+---------+-----------------+ 311 | Value | Description | DTLS-OK | Reference | 312 +-------------------+-------------+---------+-----------------+ 313 | {TBD} {0x0A,0x0A} | Reserved | Y | (this document) | 314 | {TBD} {0x1A,0x1A} | Reserved | Y | (this document) | 315 | {TBD} {0x2A,0x2A} | Reserved | Y | (this document) | 316 | {TBD} {0x3A,0x3A} | Reserved | Y | (this document) | 317 | {TBD} {0x4A,0x4A} | Reserved | Y | (this document) | 318 | {TBD} {0x5A,0x5A} | Reserved | Y | (this document) | 319 | {TBD} {0x6A,0x6A} | Reserved | Y | (this document) | 320 | {TBD} {0x7A,0x7A} | Reserved | Y | (this document) | 321 | {TBD} {0x8A,0x8A} | Reserved | Y | (this document) | 322 | {TBD} {0x9A,0x9A} | Reserved | Y | (this document) | 323 | {TBD} {0xAA,0xAA} | Reserved | Y | (this document) | 324 | {TBD} {0xBA,0xBA} | Reserved | Y | (this document) | 325 | {TBD} {0xCA,0xCA} | Reserved | Y | (this document) | 326 | {TBD} {0xDA,0xDA} | Reserved | Y | (this document) | 327 | {TBD} {0xEA,0xEA} | Reserved | Y | (this document) | 328 | {TBD} {0xFA,0xFA} | Reserved | Y | (this document) | 329 +-------------------+-------------+---------+-----------------+ 331 Additions to the TLS Cipher Suite Registry 333 The cipher suite numbers listed in the first column are numbers used 334 for cipher suite interoperability testing and it's suggested that 335 IANA use these values for assignment. 337 This document updates the Supported Groups Registry, available from 338 : 340 +-------------+-------------+---------+-----------------+ 341 | Value | Description | DTLS-OK | Reference | 342 +-------------+-------------+---------+-----------------+ 343 | {TBD} 2570 | Reserved | Y | (this document) | 344 | {TBD} 6682 | Reserved | Y | (this document) | 345 | {TBD} 10794 | Reserved | Y | (this document) | 346 | {TBD} 14906 | Reserved | Y | (this document) | 347 | {TBD} 19018 | Reserved | Y | (this document) | 348 | {TBD} 23130 | Reserved | Y | (this document) | 349 | {TBD} 27242 | Reserved | Y | (this document) | 350 | {TBD} 31354 | Reserved | Y | (this document) | 351 | {TBD} 35466 | Reserved | Y | (this document) | 352 | {TBD} 39578 | Reserved | Y | (this document) | 353 | {TBD} 43690 | Reserved | Y | (this document) | 354 | {TBD} 47802 | Reserved | Y | (this document) | 355 | {TBD} 51914 | Reserved | Y | (this document) | 356 | {TBD} 56026 | Reserved | Y | (this document) | 357 | {TBD} 60138 | Reserved | Y | (this document) | 358 | {TBD} 64250 | Reserved | Y | (this document) | 359 +-------------+-------------+---------+-----------------+ 361 Additions to the Supported Groups Registry 363 The named group numbers listed in the first column are numbers used 364 for cipher suite interoperability testing and it's suggested that 365 IANA use these values for assignment. 367 This document updates the ExtensionType Values registry, available 368 from : 370 +-------------+----------------+-----------------+ 371 | Value | Extension name | Reference | 372 +-------------+----------------+-----------------+ 373 | {TBD} 2570 | Reserved | (this document) | 374 | {TBD} 6682 | Reserved | (this document) | 375 | {TBD} 10794 | Reserved | (this document) | 376 | {TBD} 14906 | Reserved | (this document) | 377 | {TBD} 19018 | Reserved | (this document) | 378 | {TBD} 23130 | Reserved | (this document) | 379 | {TBD} 27242 | Reserved | (this document) | 380 | {TBD} 31354 | Reserved | (this document) | 381 | {TBD} 35466 | Reserved | (this document) | 382 | {TBD} 39578 | Reserved | (this document) | 383 | {TBD} 43690 | Reserved | (this document) | 384 | {TBD} 47802 | Reserved | (this document) | 385 | {TBD} 51914 | Reserved | (this document) | 386 | {TBD} 56026 | Reserved | (this document) | 387 | {TBD} 60138 | Reserved | (this document) | 388 | {TBD} 64250 | Reserved | (this document) | 389 +-------------+----------------+-----------------+ 391 Additions to the ExtensionType Values registry 393 The extension numbers listed in the first column are numbers used for 394 cipher suite interoperability testing and it's suggested that IANA 395 use these values for assignment. 397 This document updates the TLS Application-Layer Protocol Negotiation 398 (ALPN) Protocol IDs registry, available from 399 : 402 +----------+-------------------------+-----------------+ 403 | Protocol | Identification Sequence | Reference | 404 +----------+-------------------------+-----------------+ 405 | Reserved | {TBD} 0x0A 0x0A | (this document) | 406 | Reserved | {TBD} 0x1A 0x1A | (this document) | 407 | Reserved | {TBD} 0x2A 0x2A | (this document) | 408 | Reserved | {TBD} 0x3A 0x3A | (this document) | 409 | Reserved | {TBD} 0x4A 0x4A | (this document) | 410 | Reserved | {TBD} 0x5A 0x5A | (this document) | 411 | Reserved | {TBD} 0x6A 0x6A | (this document) | 412 | Reserved | {TBD} 0x7A 0x7A | (this document) | 413 | Reserved | {TBD} 0x8A 0x8A | (this document) | 414 | Reserved | {TBD} 0x9A 0x9A | (this document) | 415 | Reserved | {TBD} 0xAA 0xAA | (this document) | 416 | Reserved | {TBD} 0xBA 0xBA | (this document) | 417 | Reserved | {TBD} 0xCA 0xCA | (this document) | 418 | Reserved | {TBD} 0xDA 0xDA | (this document) | 419 | Reserved | {TBD} 0xEA 0xEA | (this document) | 420 | Reserved | {TBD} 0xFA 0xFA | (this document) | 421 +----------+-------------------------+-----------------+ 423 Additions to the ALPN Protocol IDs registry 425 7. Security Considerations 427 GREASE values may not be negotiated, so they do not directly impact 428 the security of TLS connections. 430 Historically, when interoperability problems arise in deploying new 431 TLS features, implementations have used a fallback retry on error 432 with the feature disabled. This allows an active attacker to 433 silently disable the new feature. By preventing a class of such 434 interoperability problems, GREASE reduces the need for this kind of 435 fallback. 437 If an implementation does not select GREASE values at random it is 438 possible it will allow for fingerprinting of the implementation or 439 perhaps even of individual users. This can result in a negative 440 impact to a user's privacy. 442 8. Acknowledgements 444 The author would like to thank Adam Langley, Nick Harper, and Steven 445 Valdez for their feedback and suggestions. In addition, the rusted 446 joint metaphor is originally due to Adam Langley. 448 9. Normative References 450 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 451 Requirement Levels", BCP 14, RFC 2119, 452 DOI 10.17487/RFC2119, March 1997, 453 . 455 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 456 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 457 January 2012, . 459 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 460 "Transport Layer Security (TLS) Application-Layer Protocol 461 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 462 July 2014, . 464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 466 May 2017, . 468 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 469 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 470 . 472 Author's Address 474 David Benjamin 475 Google 476 320 N Morgan St, Suite 600 477 Chicago, IL 60607 478 USA 480 Email: davidben@google.com