RFC 8701

Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility

📅 published January 2020, from ietf

RFC 8701 Part 1 of 3 🎀

Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility 🦋

Okay bestie, this is the paperwork for GREASE 🧚 It's from the Internet Engineering Task Force (IETF) and was written by D. Benjamin at Google LLC. It's marked as Category: Informational, so it's published for info and isn't a Standards Track spec 💅. The date is January 2020 and the ISSN is 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates.

Abstract 💖

Okay so GREASE (Generate Random Extensions And Sustain Extensibility) is a mechanism for stopping extensibility failures in the TLS ecosystem 😭. It reserves a set of TLS protocol values that may be advertised, so peers can make sure they handle unknown values correctly 🫶.

Status of This Memo 🌸

Not gonna lie, this part is a bit formal, but the vibe is: this is not an Internet Standards Track specification, it's just published for informational purposes 📚.

It is a product of the IETF and represents the consensus of the IETF community 🤝. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for that 🙈.

For the current status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8701 ✨.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they explain your rights and restrictions for this document 👀. Code Components taken from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚠️.

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements Language
2.  GREASE Values
3.  Client-Initiated Extension Points
  3.1.  Client Behavior
  3.2.  Server Behavior
4.  Server-Initiated Extension Points
  4.1.  Server Behavior
  4.2.  Client Behavior
5.  Sending GREASE Values
6.  IANA Considerations
7.  Security Considerations
8.  Normative References
Acknowledgments
Author's Address

1. Introduction ✨

Okay so TLS [RFC8446] has a bunch of extensibility points, like the list of cipher suites and several lists of extensions 🧩. The values in those lists are how implementations say what they can do. The model is that one side (usually the client) advertises what it supports, and the other side (usually the server) picks from it 🎯. The responding side must ignore unknown values, which is what lets new capabilities show up in the ecosystem without breaking interoperability 🌈.

Here's the tea though ☕. Bugs can make an implementation reject unknown values. That buggy version still works with existing peers, so nobody notices and the mistake spreads quietly 🙈. Later on, when new values get defined, updated peers find out that the metaphorical joint in the protocol has rusted shut, and the new values can't be deployed without interoperability failures 💀.

So this document reserves some currently unused values for TLS implementations to advertise at random 🎲. Correctly implemented peers will ignore those values and keep interoperating just fine 💖. Peers that don't tolerate unknown values will fail to interoperate, which exposes the mistake before it's everywhere 🔥.

Since the whole thing is about that rusted joint, this technique is called "GREASE" (Generate Random Extensions And Sustain Extensibility) 🫶. It's iconic, honestly 👑.

1.1. Requirements Language 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖.

2. GREASE Values 🌸

This document reserves a bunch of TLS protocol values, which we call GREASE values 🍓. They were allocated sparsely so server implementations are discouraged from conditioning on them 🙈. They also share a consistent number pattern across all the types, and they avoid colliding with any existing applicable TLS registries, so it's neat and tidy 🧁.

The following values are reserved as GREASE values for cipher suites and Application-Layer Protocol Negotiation (ALPN) [RFC7301] identifiers 🦋:

{0x0A,0x0A}
{0x1A,0x1A}
{0x2A,0x2A}
{0x3A,0x3A}
{0x4A,0x4A}
{0x5A,0x5A}
{0x6A,0x6A}
{0x7A,0x7A}
{0x8A,0x8A}
{0x9A,0x9A}
{0xAA,0xAA}
{0xBA,0xBA}
{0xCA,0xCA}
{0xDA,0xDA}
{0xEA,0xEA}
{0xFA,0xFA}

The following values are reserved as GREASE values for extensions, named groups, signature algorithms, and versions 💜:

0x0A0A
0x1A1A
0x2A2A
0x3A3A
0x4A4A
0x5A5A
0x6A6A
0x7A7A
0x8A8A
0x9A9A
0xAAAA
0xBABA
0xCACA
0xDADA
0xEAEA
0xFAFA

The values allocated above are therefore no longer available for use as TLS or DTLS [RFC6347] version numbers 🚫.

The following values are reserved as GREASE values for PskKeyExchangeModes 🌈:

0x0B
0x2A
0x49
0x68
0x87
0xA6
0xC5
0xE4

3. Client-Initiated Extension Points 🎀

Most extension points in TLS are offered by the client and selected by the server 🧚. This section covers how clients and servers should act around GREASE values for these, so pay attention 👀.

3.1. Client Behavior 💖

When sending a ClientHello, a client MAY behave as follows 🎲:

  • A client MAY select one or more GREASE cipher suite values and advertise them in the "cipher_suites" field 🧁.
  • A client MAY select one or more GREASE extension values and advertise them as extensions with varying length and contents ✨.
  • A client MAY select one or more GREASE named group values and advertise them in the "supported_groups" extension, if sent. It MAY also send KeyShareEntry values for a subset of those selected in the "key_share" extension. For each of these, the "key_exchange" field MAY be any value 🔑.
  • A client MAY select one or more GREASE signature algorithm values and advertise them in the "signature_algorithms" or "signature_algorithms_cert" extensions, if sent 🖊️.
  • A client MAY select one or more GREASE version values and advertise them in the "supported_versions" extension, if sent 🌸.
  • A client MAY select one or more GREASE PskKeyExchangeMode values and advertise them in the "psk_key_exchange_modes" extension, if sent 🦋.
  • A client MAY select one or more GREASE ALPN identifiers and advertise them in the "application_layer_protocol_negotiation" extension, if sent 💜.

Clients MUST reject GREASE values when negotiated by the server 🙅‍♀️. In particular, the client MUST fail the connection if a GREASE value appears in any of the following:

  • The "version" value in a ServerHello or HelloRetryRequest
  • The "cipher_suite" value in a ServerHello
  • Any ServerHello extension
  • Any HelloRetryRequest, EncryptedExtensions, or Certificate extension in TLS 1.3
  • The "namedcurve" value in a ServerKeyExchange for an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) cipher in TLS 1.2 [RFC5246] or earlier
  • The signature algorithm in a ServerKeyExchange signature in TLS 1.2 or earlier
  • The signature algorithm in a server CertificateVerify signature in TLS 1.3

Good news: this can be done without any special processing on the client 🌈. The client is already required to reject unknown server-selected values, so it may leave GREASE values as unknown and reuse the existing logic 🧠.

3.2. Server Behavior 🌷

When processing a ClientHello, servers MUST NOT treat GREASE values differently from any unknown value 🙅‍♀️. Servers MUST NOT negotiate any GREASE value when it's offered in a ClientHello 🚫. Servers MUST correctly ignore unknown values in a ClientHello and attempt to negotiate with one of the remaining parameters 💅. (There may not be any known parameters remaining, in which case parameter negotiation will fail 💀.)

These requirements are restatements or corollaries of existing server requirements in TLS, so nothing brand new here, just the same rules applied to GREASE 🫶.

6. IANA Considerations 🗂️

okay so this part is all about the registries 📋 this doc is updating a bunch of IANA registries (the official lists that keep track of TLS codepoints) and it's giving very organized 💅 the registry URL is https://www.iana.org/assignments/tls-parameters for the first three, and https://www.iana.org/assignments/tls-extensiontype-values for the last one.

First up is the "TLS Cipher Suites" registry 🔐 this doc adds a bunch of Reserved entries, each one a pair of bytes with the same value twice, from 0x0A up to 0xFA. Every single one is marked DTLS-OK as Y and Recommended as N, and they all point back to [RFC8701] 🦋

+-------------+-------------+---------+-------------+-----------+
|    Value    | Description | DTLS-OK | Recommended | Reference |
+=============+=============+=========+=============+===========+
| {0x0A,0x0A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0x1A,0x1A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0x2A,0x2A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0x3A,0x3A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0x4A,0x4A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0x5A,0x5A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0x6A,0x6A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0x7A,0x7A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0x8A,0x8A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0x9A,0x9A} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0xAA,0xAA} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0xBA,0xBA} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0xCA,0xCA} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0xDA,0xDA} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0xEA,0xEA} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+
| {0xFA,0xFA} |   Reserved  |    Y    |      N      | [RFC8701] |
+-------------+-------------+---------+-------------+-----------+

        Table 1: Additions to the TLS Cipher Suites Registry

Next is the "TLS Supported Groups" registry 🌸 same vibe here. The doc adds Reserved entries at 2570, 6682, 10794, 14906, 19018, 23130, 27242, 31354, 35466, 39578, 43690, 47802, 51914, 56026, 60138, and 64250. They're all DTLS-OK Y, Recommended N, and reference [RFC8701] 💖

+-------+-------------+---------+-------------+-----------+
| Value | Description | DTLS-OK | Recommended | Reference |
+=======+=============+=========+=============+===========+
|  2570 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
|  6682 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 10794 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 14906 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 19018 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 23130 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 27242 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 31354 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 35466 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 39578 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 43690 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 47802 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 51914 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 56026 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 60138 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+
| 64250 |   Reserved  |    Y    |      N      | [RFC8701] |
+-------+-------------+---------+-------------+-----------+

      Table 2: Additions to the TLS Supported Groups Registry

Then there's the "TLS ExtensionType Values" registry 🎀 the doc updates it at https://www.iana.org/assignments/tls-extensiontype-values and adds the same 16 Reserved values, with the TLS 1.3 column set to CH, CR, NST and Recommended set to N. Still [RFC8701] for the reference 🫶

+-------+----------------+-------------+-------------+-----------+
| Value | Extension Name |   TLS 1.3   | Recommended | Reference |
+=======+================+=============+=============+===========+
|  2570 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
|  6682 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 10794 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 14906 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 19018 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 23130 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 27242 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 31354 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 35466 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 39578 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 43690 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 47802 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 51914 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 56026 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 60138 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+
| 64250 |    Reserved    | CH, CR, NST |      N      | [RFC8701] |
+-------+----------------+-------------+-------------+-----------+

   Table 3: Additions to the TLS ExtensionType Values Registry

Last one: the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry 🌈 this one lives at the same https://www.iana.org/assignments/tls-extensiontype-values URL, and the doc adds 16 Reserved identification sequences, from 0x0A 0x0A all the way to 0xFA 0xFA, each citing [RFC8701] ⭐

+----------+-------------------------+-----------+
| Protocol | Identification Sequence | Reference |
+==========+=========================+===========+
| Reserved |        0x0A 0x0A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0x1A 0x1A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0x2A 0x2A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0x3A 0x3A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0x4A 0x4A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0x5A 0x5A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0x6A 0x6A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0x7A 0x7A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0x8A 0x8A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0x9A 0x9A        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0xAA 0xAA        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0xBA 0xBA        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0xCA 0xCA        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0xDA 0xDA        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0xEA 0xEA        | [RFC8701] |
+----------+-------------------------+-----------+
| Reserved |        0xFA 0xFA        | [RFC8701] |
+----------+-------------------------+-----------+

            Table 4: Additions to the TLS Application-
          Layer Protocol Negotiation (ALPN) Protocol IDs
                             Registry

7. Security Considerations 🔒

okay bestie, security time and this part is kinda the most important 😭 first thing: GREASE values cannot be negotiated, so they do not directly impact the security of TLS connections. phew 🫶

BUT there's a sneaky catch 🙈 historically, when interop problems pop up while people are rolling out new TLS features, implementations tend to do a fallback retry on error with the feature turned off. and that lets an active attacker quietly switch the new feature off 👀 GREASE helps prevent a whole class of those interop problems, so it cuts down on the need for that kind of fallback.

Implementations SHOULD NOT retry with GREASE disabled on connection failure. ⚠️ Yes, even though letting an attacker turn GREASE off probably won't have immediate security consequences, that fallback would stop GREASE from protecting us against extensibility failures, and that's the whole point of GREASE 💀

Last bit: if an implementation doesn't pick GREASE values at random, it could allow fingerprinting of the implementation, or maybe even of individual users 🥺 and that can seriously hurt a user's privacy. so randomize those values, periodt 💅✨

8. Normative References ✨

okay bestie, this is the reading list 📚 these are the docs the spec leans on so hard it literally can't work without them. the key words ([RFC2119] and [RFC8174]) are how we say what's a must, a should, or a may 💅

Acknowledgments 🫶

bestie, big thank yous to Adam Langley, Nick Harper, and Steven Valdez for giving feedback and suggestions 💖 and the rusted joint metaphor? that one's originally Adam Langley's 🦋 iconic, no notes 😭

Author's Address 💌

David Benjamin Google LLC

Email: davidben@google.com

📦 where this page comes from