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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04



Internet Engineering Task Force (IETF)                       D. Benjamin
Request for Comments: 8701                                    Google LLC
Category: Informational                                     January 2020
ISSN: 2070-1721

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

Abstract

   This document describes GREASE (Generate Random Extensions And
   Sustain Extensibility), a mechanism to prevent extensibility failures
   in the TLS ecosystem.  It reserves a set of TLS protocol values that
   may be advertised to ensure peers correctly handle unknown values.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8701.

Copyright Notice

   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) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided 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

   The TLS protocol [RFC8446] includes several points of extensibility,
   including the list of cipher suites and several lists of extensions.
   The values transmitted in these lists identify implementation
   capabilities.  TLS follows a model where one side, usually the
   client, advertises capabilities, and the peer, usually the server,
   selects them.  The responding side must ignore unknown values so that
   new capabilities may be introduced to the ecosystem while maintaining
   interoperability.

   However, bugs may cause an implementation to reject unknown values.
   It will interoperate with existing peers, so the mistake may spread
   through the ecosystem unnoticed.  Later, when new values are defined,
   updated peers will discover that the metaphorical joint in the
   protocol has rusted shut and the new values cannot be deployed
   without interoperability failures.

   To avoid this problem, this document reserves some currently unused
   values for TLS implementations to advertise at random.  Correctly
   implemented peers will ignore these values and interoperate.  Peers
   that do not tolerate unknown values will fail to interoperate,
   revealing the mistake before it is widespread.

   In keeping with the rusted joint metaphor, this technique is called
   "GREASE" (Generate Random Extensions And Sustain Extensibility).

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 number of TLS protocol values, referred to
   as GREASE values.  These values were allocated sparsely to discourage
   server implementations from conditioning on them.  For convenience,
   they were also chosen so all types share a number scheme with a
   consistent pattern while avoiding collisions with any existing
   applicable registries in TLS.

   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}