rfc8701xml2.original.xml   rfc8701.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
FC.2119.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
FC.5246.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
FC.6347.xml">
<!ENTITY RFC7301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
FC.7301.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
FC.8174.xml">
<!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
FC.8446.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-ietf-tls-grease-04" ipr="trust200902">
<front>
<title>Applying GREASE to TLS Extensibility</title>
<author fullname="David Benjamin" initials="D." surname="Benjamin"> <rfc number="8701" xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
<organization>Google LLC</organization> consensus="true" docName="draft-ietf-tls-grease-04" ipr="trust200902" obsol
<address> etes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDept
<email>davidben@google.com</email> h="4" symRefs="true" sortRefs="true" version="3">
</address>
</author>
<date year="2019" /> <front>
<area>General</area> <title>Applying Generate Random Extensions And Sustain Extensibility (GREASE
) to TLS Extensibility</title>
<seriesInfo name="RFC" value="8701"/>
<author fullname="David Benjamin" initials="D." surname="Benjamin">
<organization>Google LLC</organization>
<address>
<email>davidben@google.com</email>
</address>
</author>
<date year="2020" month="January"/>
<area>General</area>
<abstract> <keyword>TLS, GREASE</keyword>
<t>This document describes GREASE (Generate Random Extensions And Sustain
<abstract>
<t>This document describes GREASE (Generate Random Extensions And Sustain
Extensibility), a mechanism to prevent extensibility failures in the TLS Extensibility), a mechanism to prevent extensibility failures in the TLS
ecosystem. It reserves a set of TLS protocol values that may be advertised ecosystem. It reserves a set of TLS protocol values that may be advertised
to ensure peers correctly handle unknown values.</t> to ensure peers correctly handle unknown values.</t>
</abstract> </abstract>
</front> </front>
<middle>
<middle> <section numbered="true" toc="default">
<section title="Introduction"> <name>Introduction</name>
<t>The TLS protocol <xref target="RFC8446" /> includes several points of <t>The TLS protocol <xref target="RFC8446" format="default"/> includes sev
eral points of
extensibility, including the list of cipher suites and several lists of extensio ns. extensibility, including the list of cipher suites and several lists of extensio ns.
The values transmitted in these lists identify implementation capabilities. TLS follows The values transmitted in these lists identify implementation capabilities. TLS follows
a model where one side, usually the client, advertises capabilities and the a model where one side, usually the client, advertises capabilities, and the
peer, usually the server, selects them. The responding side must ignore unknown peer, usually the server, selects them. The responding side must ignore unknown
values so that new capabilities may be introduced to the ecosystem while values so that new capabilities may be introduced to the ecosystem while
maintaining interoperability.</t> maintaining interoperability.</t>
<t>However, bugs may cause an implementation to reject unknown
<t>However, bugs may cause an implementation to reject unknown values. It will values. It will interoperate with existing peers, so the mistake may
interoperate with existing peers, so the mistake may spread through the spread through the ecosystem unnoticed. Later, when new values are
ecosystem unnoticed. Later, when new values are defined, updated peers will defined, updated peers will discover that the metaphorical joint in the
discover that the metaphorical joint in the protocol has rusted shut and that protocol has rusted shut and the new values cannot be deployed without
the new values cannot be deployed without interoperability failures.</t> interoperability failures.</t>
<t>To avoid this problem, this document reserves some currently unused val
<t>To avoid this problem, this document reserves some currently unused values fo ues for
r
TLS implementations to advertise at random. Correctly implemented peers will ign ore TLS implementations to advertise at random. Correctly implemented peers will ign ore
these values and interoperate. Peers that do not tolerate unknown values will these values and interoperate. Peers that do not tolerate unknown values will
fail to interoperate, revealing the mistake before it is fail to interoperate, revealing the mistake before it is
widespread.</t> widespread.</t>
<t>In keeping with the rusted joint metaphor, this technique is called "GR
<t>In keeping with the rusted joint metaphor, this technique is named GREASE EASE"
(Generate Random Extensions And Sustain Extensibility).</t> (Generate Random Extensions And Sustain Extensibility).</t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
BCP 14 <xref target="RFC2119">RFC 2119</xref>[RFC2119] <xref RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
target="RFC8174">RFC 8174</xref> when, and only when, they appear "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
in all capitals, as shown here.</t> be interpreted as
</section> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</t>
<section title="GREASE Values"> </section>
<t>This document reserves a number of TLS protocol values, referred to as </section>
<section numbered="true" toc="default">
<name>GREASE Values</name>
<t>This document reserves a number of TLS protocol values, referred to as
GREASE values. These values were allocated sparsely to discourage server GREASE values. These values were allocated sparsely to discourage server
implementations from conditioning on them. For convenience, they were also implementations from conditioning on them. For convenience, they were also
chosen so all types share a number scheme with a consistent pattern while chosen so all types share a number scheme with a consistent pattern while
avoiding collisions with any existing applicable registries in TLS.</t> avoiding collisions with any existing applicable registries in TLS.</t>
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH. The values prefaced <t>The following values are reserved as GREASE values for cipher suites
with {TBD} are suggested values and subject to change prior to final and Application-Layer Protocol Negotiation (ALPN) <xref target="RFC7301" fo
allocation by IANA.</t> rmat="default"/> identifiers:</t>
<t>The following values are reserved as GREASE values for cipher suites
and ALPN <xref target="RFC7301" /> identifiers:</t>
<?rfc subcompact="yes" ?> <ul empty="true">
<t><list> <li>{0x0A,0x0A}
<t>{TBD} {0x0A,0x0A}</t> </li>
<t>{TBD} {0x1A,0x1A}</t> <li>{0x1A,0x1A}
<t>{TBD} {0x2A,0x2A}</t> </li>
<t>{TBD} {0x3A,0x3A}</t> <li>{0x2A,0x2A}
<t>{TBD} {0x4A,0x4A}</t> </li>
<t>{TBD} {0x5A,0x5A}</t> <li>{0x3A,0x3A}
<t>{TBD} {0x6A,0x6A}</t> </li>
<t>{TBD} {0x7A,0x7A}</t> <li>{0x4A,0x4A}
<t>{TBD} {0x8A,0x8A}</t> </li>
<t>{TBD} {0x9A,0x9A}</t> <li>{0x5A,0x5A}
<t>{TBD} {0xAA,0xAA}</t> </li>
<t>{TBD} {0xBA,0xBA}</t> <li>{0x6A,0x6A}
<t>{TBD} {0xCA,0xCA}</t> </li>
<t>{TBD} {0xDA,0xDA}</t> <li>{0x7A,0x7A}
<t>{TBD} {0xEA,0xEA}</t> </li>
<t>{TBD} {0xFA,0xFA}</t> <li>{0x8A,0x8A}
</list></t> </li>
<?rfc subcompact="no" ?> <li>{0x9A,0x9A}
</li>
<li>{0xAA,0xAA}
</li>
<li>{0xBA,0xBA}
</li>
<li>{0xCA,0xCA}
</li>
<li>{0xDA,0xDA}
</li>
<li>{0xEA,0xEA}
</li>
<li>{0xFA,0xFA}
</li>
</ul>
<t>The following values are reserved as GREASE values for extensions, <t>The following values are reserved as GREASE values for extensions,
named groups, signature algorithms, and versions:</t> named groups, signature algorithms, and versions:</t>
<?rfc subcompact="yes" ?> <ul empty="true">
<t><list> <li>0x0A0A
<t>{TBD} 0x0A0A</t> </li>
<t>{TBD} 0x1A1A</t> <li>0x1A1A
<t>{TBD} 0x2A2A</t> </li>
<t>{TBD} 0x3A3A</t> <li>0x2A2A
<t>{TBD} 0x4A4A</t> </li>
<t>{TBD} 0x5A5A</t> <li>0x3A3A
<t>{TBD} 0x6A6A</t> </li>
<t>{TBD} 0x7A7A</t> <li>0x4A4A
<t>{TBD} 0x8A8A</t> </li>
<t>{TBD} 0x9A9A</t> <li>0x5A5A
<t>{TBD} 0xAAAA</t> </li>
<t>{TBD} 0xBABA</t> <li>0x6A6A
<t>{TBD} 0xCACA</t> </li>
<t>{TBD} 0xDADA</t> <li>0x7A7A
<t>{TBD} 0xEAEA</t> </li>
<t>{TBD} 0xFAFA</t> <li>0x8A8A
</list></t> </li>
<?rfc subcompact="no" ?> <li>0x9A9A
</li>
<t>The values allocated above are thus no longer available for use as TLS o <li>0xAAAA
r </li>
DTLS <xref target="RFC6347" /> version numbers.</t> <li>0xBABA
</li>
<li>0xCACA
</li>
<li>0xDADA
</li>
<li>0xEAEA
</li>
<li>0xFAFA
</li>
</ul>
<t>The following values are reserved as GREASE values for PskKeyExchangeMod <t>The values allocated above are thus no longer available for use as TLS
es.</t> or
DTLS <xref target="RFC6347" format="default"/> version numbers.</t>
<t>The following values are reserved as GREASE values for PskKeyExchangeMo
des:</t>
<?rfc subcompact="yes" ?> <ul empty="true">
<t><list> <li>0x0B
<t>{TBD} 0x0B</t> </li>
<t>{TBD} 0x2A</t> <li>0x2A
<t>{TBD} 0x49</t> </li>
<t>{TBD} 0x68</t> <li>0x49
<t>{TBD} 0x87</t> </li>
<t>{TBD} 0xA6</t> <li>0x68
<t>{TBD} 0xC5</t> </li>
<t>{TBD} 0xE4</t> <li>0x87
</list></t> </li>
<?rfc subcompact="no" ?> <li>0xA6
</section> </li>
<li>0xC5
</li>
<li>0xE4
</li>
</ul>
<section title="Client-Initiated Extension Points"> </section>
<t>Most extension points in TLS are offered by the client and selected by <section numbered="true" toc="default">
<name>Client-Initiated Extension Points</name>
<t>Most extension points in TLS are offered by the client and selected by
the server. This section details client and server behavior around the server. This section details client and server behavior around
GREASE values for these.</t> GREASE values for these.</t>
<section numbered="true" toc="default">
<name>Client Behavior</name>
<t>When sending a ClientHello, a client <bcp14>MAY</bcp14> behave as fol
lows:</t>
<ul spacing="normal">
<li>A client <bcp14>MAY</bcp14> select one or more GREASE cipher suite
values and advertise them in the "cipher_suites" field.</li>
<li>A client <bcp14>MAY</bcp14> select one or more GREASE extension va
lues and advertise them as extensions with varying length and contents.</li>
<li>A client <bcp14>MAY</bcp14> select one or more GREASE named group
values and advertise them in the "supported_groups" extension, if sent. It <bcp1
4>MAY</bcp14> also send KeyShareEntry values for a subset of those selected in t
he "key_share" extension. For each of these, the "key_exchange" field <bcp14>MAY
</bcp14> be any value.</li>
<li>A client <bcp14>MAY</bcp14> select one or more GREASE signature al
gorithm values and advertise them in the "signature_algorithms" or "signature_al
gorithms_cert" extensions, if sent.</li>
<li>A client <bcp14>MAY</bcp14> select one or more GREASE version valu
es and advertise them in the "supported_versions" extension, if sent.</li>
<li>A client <bcp14>MAY</bcp14> select one or more GREASE PskKeyExchan
geMode values and advertise them in the "psk_key_exchange_modes" extension, if s
ent.</li>
<li>A client <bcp14>MAY</bcp14> select one or more GREASE ALPN identif
iers and advertise them in the "application_layer_protocol_negotiation" extensio
n, if sent.</li>
</ul>
<section title="Client Behavior"> <t>Clients <bcp14>MUST</bcp14> reject GREASE values when negotiated by
the server. In particular, the client <bcp14>MUST</bcp14> fail the
<t>When sending a ClientHello, a client MAY behave as follows:</t> connection if a GREASE value appears in any of the following:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The "version" value in a ServerHello or HelloRetryRequest</li>
<t>A client MAY select one or more GREASE cipher suite values and adver <li>The "cipher_suite" value in a ServerHello</li>
tise them in the "cipher_suites" field.</t> <li>Any ServerHello extension</li>
<t>A client MAY select one or more GREASE extension values and advertis <li>Any HelloRetryRequest, EncryptedExtensions, or Certificate extensi
e them as extensions with varying length and contents.</t> on in TLS 1.3</li>
<t>A client MAY select one or more GREASE named group values and advert <li>The "namedcurve" value in a ServerKeyExchange for an Ephemeral
ise them in the "supported_groups" extension, if sent. It MAY also send KeyShare Elliptic Curve Diffie-Hellman (ECDHE) cipher in TLS 1.2 <xref
Entry values for a subset of those selected in the "key_share" extension. For ea target="RFC5246" format="default"/> or earlier</li>
ch of these, the "key_exchange" field MAY be any value.</t> <li>The signature algorithm in a ServerKeyExchange signature in TLS 1.
<t>A client MAY select one or more GREASE signature algorithm values an 2 or earlier</li>
d advertise them in the "signature_algorithms" or "signature_algorithms_cert" ex <li>The signature algorithm in a server CertificateVerify signature in
tensions, if sent.</t> TLS 1.3</li>
<t>A client MAY select one or more GREASE version values and advertise </ul>
them in the "supported_versions" extension, if sent.</t> <t>Note that this can be implemented without special processing on the c
<t>A client MAY select one or more GREASE PskKeyExchangeMode values and lient. The client
advertise them in the "psk_key_exchange_modes" extension, if sent.</t>
<t>A client MAY select one or more GREASE ALPN identifiers and advertis
e them in the "application_layer_protocol_negotiation" extension, if sent.</t>
</list></t>
<t>Clients MUST reject GREASE values when negotiated by the server.
In particular, the client MUST fail the connection if a GREASE value appears any
in the following:</t>
<t><list style="symbols">
<t>The "version" value in a ServerHello or HelloRetryRequest</t>
<t>The "cipher_suite" value in a ServerHello</t>
<t>Any ServerHello extension</t>
<t>Any HelloRetryRequest, EncryptedExtensions, or Certificate extension
in TLS 1.3</t>
<t>The "namedcurve" value in a ServerKeyExchange for an ECDHE cipher in
TLS 1.2 <xref target="RFC5246" /> or earlier</t>
<t>The signature algorithm in a ServerKeyExchange signature in TLS 1.2
or earlier</t>
<t>The signature algorithm in a server CertificateVerify signature in T
LS 1.3</t>
</list></t>
<t>Note that this can be implemented without special processing on the clie
nt. The client
is already required to reject unknown server-selected values, so it is already required to reject unknown server-selected values, so it
may leave GREASE values as unknown and reuse the existing logic.</t> may leave GREASE values as unknown and reuse the existing logic.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Server Behavior"> <name>Server Behavior</name>
<t> <t>
When processing a ClientHello, servers MUST NOT treat GREASE values differently When processing a ClientHello, servers <bcp14>MUST NOT</bcp14> treat GREASE valu
from any unknown value. es differently from any unknown value.
Servers MUST NOT negotiate any GREASE value when offered in a ClientHello. Servers <bcp14>MUST NOT</bcp14> negotiate any GREASE value when offered in a Cli
Servers MUST correctly ignore unknown values in a ClientHello and attempt to neg entHello.
otiate with one of the remaining parameters. Servers <bcp14>MUST</bcp14> 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 negoti ation will fail.) (There may not be any known parameters remaining, in which case parameter negoti ation will fail.)
</t> </t>
<t>Note that these requirements are restatements or corollaries of
<t>Note that these requirements are restatements or corollaries of
existing server requirements in TLS.</t> existing server requirements in TLS.</t>
</section> </section>
</section>
</section> <section numbered="true" toc="default">
<name>Server-Initiated Extension Points</name>
<section title="Server-Initiated Extension Points"> <t>Some extension points are offered by the server and selected by the
<t>Some extension points are offered by the server and selected by the
client. This section details client and server behavior around GREASE client. This section details client and server behavior around GREASE
values for these.</t> values for these.</t>
<section numbered="true" toc="default">
<section title="Server Behavior"> <name>Server Behavior</name>
<t>When sending a CertificateRequest in TLS 1.3, a server MAY behave as fol <t>When sending a CertificateRequest in TLS 1.3, a server <bcp14>MAY</bc
lows:</t> p14> behave as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>A server <bcp14>MAY</bcp14> select one or more GREASE extension va
<t>A server MAY select one or more GREASE extension values and advertis lues and advertise them as extensions with varying length and contents.</li>
e them as extensions with varying length and contents.</t> <li>A server <bcp14>MAY</bcp14> select one or more GREASE signature al
<t>A server MAY select one or more GREASE signature algorithm values an gorithm values and advertise them in the "signature_algorithms" or "signature_al
d advertise them in the "signature_algorithms" or "signature_algorithms_cert" ex gorithms_cert" extensions, if present.</li>
tensions, if present.</t> </ul>
</list></t> <t>When sending a NewSessionTicket message in TLS 1.3, a server <bcp14>M
AY</bcp14> select one or more GREASE extension values and advertise them as exte
<t>When sending a NewSessionTicket message in TLS 1.3, a server MAY select nsions with varying length and contents.</t>
one or more GREASE extension values and advertise them as extensions with varyin <t>Servers <bcp14>MUST</bcp14> reject GREASE values when negotiated by t
g length and contents.</t> he client.
In particular, the server <bcp14>MUST</bcp14> fail the connection if a GREASE
<t>Servers MUST reject GREASE values when negotiated by the client. value appears in any of the following:</t>
In particular, the server MUST fail the connection if a GREASE value appears any <ul spacing="normal">
in the following:</t> <li>Any Certificate extension in TLS 1.3</li>
<li>The signature algorithm in a client CertificateVerify signature</l
<t><list style="symbols"> i>
<t>Any Certificate extension in TLS 1.3</t> </ul>
<t>The signature algorithm in a client CertificateVerify signature</t> <t>Note that this can be implemented without special processing on the s
</list></t> erver. The server
<t>Note that this can be implemented without special processing on the serv
er. The server
is already required to reject unknown client-selected values, so it is already required to reject unknown client-selected values, so it
may leave GREASE values as unknown and reuse the existing logic.</t> may leave GREASE values as unknown and reuse the existing logic.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Client Behavior"> <name>Client Behavior</name>
<t> <t>
When processing a CertificateRequest or NewSessionTicket, clients MUST NOT treat When processing a CertificateRequest or NewSessionTicket, clients <bcp14>MUST NO
GREASE values differently from any unknown value. T</bcp14> treat GREASE values differently from any unknown value.
Clients MUST NOT negotiate any GREASE value when offered by the server. Clients <bcp14>MUST NOT</bcp14> negotiate any GREASE value when offered by the s
Clients MUST correctly ignore unknown values offered by the server and attempt t erver.
o negotiate with one of the remaining parameters. Clients <bcp14>MUST</bcp14> correctly ignore unknown values offered by the serve
r and attempt to negotiate with one of the remaining parameters.
(There may not be any known parameters remaining, in which case parameter negoti ation will fail.) (There may not be any known parameters remaining, in which case parameter negoti ation will fail.)
</t> </t>
<t>Note that these requirements are restatements or corollaries of
<t>Note that these requirements are restatements or corollaries of
existing client requirements in TLS.</t> existing client requirements in TLS.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Sending GREASE Values"> <name>Sending GREASE Values</name>
<t>Implementations advertising GREASE values SHOULD select them at random. <t>Implementations advertising GREASE values <bcp14>SHOULD</bcp14> select
them at random.
This is intended to encourage implementations to ignore all unknown values This is intended to encourage implementations to ignore all unknown values
rather than any individual value. Implementations MUST honor protocol rather than any individual value. Implementations <bcp14>MUST</bcp14> honor prot
specifications when sending GREASE values. For instance, section 4.2 of ocol
<xref target="RFC8446" /> forbids duplicate extension types within a single specifications when sending GREASE values. For instance, <xref target="RFC8446"
sectionFormat="of" section="4.2"/> forbids duplicate extension types within a si
ngle
extension block. Implementations sending multiple GREASE extensions in a single extension block. Implementations sending multiple GREASE extensions in a single
block thus must ensure the same value is not selected twice.</t> block must therefore ensure the same value is not selected twice.</t>
<t>Implementations <bcp14>SHOULD</bcp14> balance diversity in GREASE adver
<t>Implementations SHOULD balance diversity in GREASE advertisements with dete tisements with determinism.
rminism. For example, a client that randomly varies GREASE value positions for each
For example, a client which randomly varies GREASE value positions for each
connection may only fail against a broken server with some probability. This connection may only fail against a broken server with some probability. This
risks the failure being masked by automatic retries. A client which positions risks the failure being masked by automatic retries. A client that positions
GREASE values deterministically over a period of time (such as a single GREASE values deterministically over a period of time (such as a single
software release) stresses fewer cases but is more likely to detect bugs from software release) stresses fewer cases but is more likely to detect bugs from
those cases.</t> those cases.</t>
</section> </section>
<section anchor="IANA" title="IANA Considerations">
<t>This document updates the TLS Cipher Suite Registry, available from
<eref target="https://www.iana.org/assignments/tls-parameters"/>:</t>
<texttable title="Additions to the TLS Cipher Suite Registry">
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>DTLS-OK</ttcol>
<ttcol align='center'>Recommended</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>{TBD} {0x0A,0x0A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0x1A,0x1A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0x2A,0x2A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0x3A,0x3A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0x4A,0x4A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0x5A,0x5A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0x6A,0x6A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0x7A,0x7A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0x8A,0x8A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0x9A,0x9A}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0xAA,0xAA}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0xBA,0xBA}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0xCA,0xCA}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0xDA,0xDA}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0xEA,0xEA}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
<c>{TBD} {0xFA,0xFA}</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this docum
ent)</c>
</texttable>
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH. The cipher suite numb
ers listed in the first column are numbers used for interoperability testing and
it's suggested that IANA use these values for assignment.</t>
<t>This document updates the Supported Groups Registry, available from
<eref target="https://www.iana.org/assignments/tls-parameters"/>:</t>
<texttable title="Additions to the Supported Groups Registry">
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>DTLS-OK</ttcol>
<ttcol align='center'>Recommended</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>{TBD} 2570</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 6682</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 10794</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 14906</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 19018</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 23130</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 27242</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 31354</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 35466</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 39578</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 43690</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 47802</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 51914</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 56026</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 60138</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
<c>{TBD} 64250</c> <c>Reserved</c> <c>Y</c> <c>N</c> <c>(this document)</
c>
</texttable>
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH. The named group numbe
rs listed in the first column are numbers used for interoperability testing and
it's suggested that IANA use these values for assignment.</t>
<t>This document updates the ExtensionType Values registry, available from
<eref target="https://www.iana.org/assignments/tls-extensiontype-values"/>:</t>
<texttable title="Additions to the ExtensionType Values registry">
<ttcol align='center'>Value</ttcol>
<ttcol align='center'>Extension name</ttcol>
<ttcol align='center'>TLS 1.3</ttcol>
<ttcol align='center'>Recommended</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>{TBD} 2570</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 6682</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 10794</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 14906</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 19018</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 23130</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 27242</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 31354</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 35466</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 39578</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 43690</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 47802</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 51914</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 56026</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 60138</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
<c>{TBD} 64250</c> <c>Reserved</c> <c>CH, CR, NST</c> <c>N</c> <c>(this d
ocument)</c>
</texttable>
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH. The extension numbers
listed in the first column are numbers used for interoperability testing and it
's suggested that IANA use these values for assignment.</t>
<t>This document updates the TLS Application-Layer Protocol Negotiation <section anchor="IANA" numbered="true" toc="default">
(ALPN) Protocol IDs registry, available from <name>IANA Considerations</name>
<eref target="https://www.iana.org/assignments/tls-extensiontype-values/t <t>This document updates the &quot;TLS Cipher Suites&quot; registry, avail
ls-extensiontype-values"/>:</t> able at
<eref target="https://www.iana.org/assignments/tls-parameters" brackets="an
gle"/>:</t>
<table align="center">
<name>Additions to the TLS Cipher Suites Registry</name>
<thead >
<tr >
<th align="center">Value</th>
<th align="center">Description</th>
<th align="center">DTLS-OK</th>
<th align="center">Recommended</th>
<th align="center">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">{0x0A,0x0A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0x1A,0x1A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0x2A,0x2A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0x3A,0x3A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0x4A,0x4A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0x5A,0x5A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0x6A,0x6A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0x7A,0x7A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0x8A,0x8A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0x9A,0x9A}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0xAA,0xAA}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0xBA,0xBA}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0xCA,0xCA}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0xDA,0xDA}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0xEA,0xEA}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">{0xFA,0xFA}</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
</tbody>
</table>
<texttable title="Additions to the ALPN Protocol IDs registry"> <t>This document updates the &quot;TLS Supported Groups&quot; registry, av
<ttcol align='center'>Protocol</ttcol> ailable at
<ttcol align='center'>Identification Sequence</ttcol> <eref target="https://www.iana.org/assignments/tls-parameters" brackets="angle"/
<ttcol align='center'>Reference</ttcol> >:</t>
<c>Reserved</c> <c>{TBD} 0x0A 0x0A</c> <c>(this document)</c> <table align="center">
<c>Reserved</c> <c>{TBD} 0x1A 0x1A</c> <c>(this document)</c> <name>Additions to the TLS Supported Groups Registry</name>
<c>Reserved</c> <c>{TBD} 0x2A 0x2A</c> <c>(this document)</c> <thead>
<c>Reserved</c> <c>{TBD} 0x3A 0x3A</c> <c>(this document)</c> <tr>
<c>Reserved</c> <c>{TBD} 0x4A 0x4A</c> <c>(this document)</c> <th align="center">Value</th>
<c>Reserved</c> <c>{TBD} 0x5A 0x5A</c> <c>(this document)</c> <th align="center">Description</th>
<c>Reserved</c> <c>{TBD} 0x6A 0x6A</c> <c>(this document)</c> <th align="center">DTLS-OK</th>
<c>Reserved</c> <c>{TBD} 0x7A 0x7A</c> <c>(this document)</c> <th align="center">Recommended</th>
<c>Reserved</c> <c>{TBD} 0x8A 0x8A</c> <c>(this document)</c> <th align="center">Reference</th>
<c>Reserved</c> <c>{TBD} 0x9A 0x9A</c> <c>(this document)</c> </tr>
<c>Reserved</c> <c>{TBD} 0xAA 0xAA</c> <c>(this document)</c> </thead>
<c>Reserved</c> <c>{TBD} 0xBA 0xBA</c> <c>(this document)</c> <tbody>
<c>Reserved</c> <c>{TBD} 0xCA 0xCA</c> <c>(this document)</c> <tr>
<c>Reserved</c> <c>{TBD} 0xDA 0xDA</c> <c>(this document)</c> <td align="center">2570</td>
<c>Reserved</c> <c>{TBD} 0xEA 0xEA</c> <c>(this document)</c> <td align="center">Reserved</td>
<c>Reserved</c> <c>{TBD} 0xFA 0xFA</c> <c>(this document)</c> <td align="center">Y</td>
</texttable> <td align="center">N</td>
</section> <td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">6682</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">10794</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">14906</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">19018</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">23130</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">27242</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">31354</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">35466</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">39578</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">43690</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">47802</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">51914</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">56026</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">60138</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">64250</td>
<td align="center">Reserved</td>
<td align="center">Y</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
</tbody>
</table>
<section anchor="Security" title="Security Considerations"> <t>This document updates the &quot;TLS ExtensionType Values&quot; registry
<t>GREASE values cannot be negotiated, so they do not directly impact the , available at
<eref
target="https://www.iana.org/assignments/tls-extensiontype-values"
brackets="angle"/>:</t>
<table align="center">
<name>Additions to the TLS ExtensionType Values Registry</name>
<thead>
<tr>
<th align="center">Value</th>
<th align="center">Extension Name</th>
<th align="center">TLS 1.3</th>
<th align="center">Recommended</th>
<th align="center">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">2570</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">6682</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">10794</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">14906</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">19018</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">23130</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">27242</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">31354</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">35466</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">39578</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">43690</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">47802</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">51914</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">56026</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">60138</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">64250</td>
<td align="center">Reserved</td>
<td align="center">CH, CR, NST</td>
<td align="center">N</td>
<td align="center">[RFC8701]</td>
</tr>
</tbody>
</table>
<t>This document updates the &quot;TLS Application-Layer Protocol Negotiat
ion
(ALPN) Protocol IDs&quot; registry, available at
<eref
target="https://www.iana.org/assignments/tls-extensiontype-values"
brackets="angle"/>:</t>
<table align="center">
<name>Additions to the TLS Application-Layer Protocol Negotiation
(ALPN) Protocol IDs Registry</name>
<thead>
<tr>
<th align="center">Protocol</th>
<th align="center">Identification Sequence</th>
<th align="center">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">Reserved</td>
<td align="center">0x0A 0x0A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0x1A 0x1A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0x2A 0x2A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0x3A 0x3A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0x4A 0x4A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0x5A 0x5A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0x6A 0x6A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0x7A 0x7A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0x8A 0x8A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0x9A 0x9A</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0xAA 0xAA</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0xBA 0xBA</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0xCA 0xCA</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0xDA 0xDA</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0xEA 0xEA</td>
<td align="center">[RFC8701]</td>
</tr>
<tr>
<td align="center">Reserved</td>
<td align="center">0xFA 0xFA</td>
<td align="center">[RFC8701]</td>
</tr>
</tbody>
</table>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>GREASE values cannot be negotiated, so they do not directly impact the
security of TLS connections.</t> security of TLS connections.</t>
<t>Historically, when interoperability problems arise in deploying new TLS
<t>Historically, when interoperability problems arise in deploying new TLS
features, implementations have used a fallback retry on error with the features, implementations have used a fallback retry on error with the
feature disabled. This allows an active attacker to silently disable the feature disabled. This allows an active attacker to silently disable the
new feature. By preventing a class of such interoperability problems, new feature. By preventing a class of such interoperability problems,
GREASE reduces the need for this kind of fallback. Implementations SHOULD GREASE reduces the need for this kind of fallback. Implementations <bcp14>S
NOT retry with GREASE disabled on connection failure. While allowing an HOULD
NOT</bcp14> retry with GREASE disabled on connection failure. While allowin
g an
attacker to disable GREASE is unlikely to have immediate security attacker to disable GREASE is unlikely to have immediate security
consequences, such a fallback would prevent GREASE from defending against consequences, such a fallback would prevent GREASE from defending against
extensibility failures.</t> extensibility failures.</t>
<t>If an implementation does not select GREASE values at random, it is
<t>If an implementation does not select GREASE values at random it is
possible it will allow for fingerprinting of the implementation or possible it will allow for fingerprinting of the implementation or
perhaps even of individual users. This can result in a negative impact to perhaps even of individual users. This can result in a negative impact to
a user's privacy.</t> a user's privacy.</t>
</section> </section>
<section anchor="Acknowledgments" title="Acknowledgments"> </middle>
<t> <back>
The author would like to thank Adam Langley, Nick Harper, and Steven Valdez for <references>
their feedback and suggestions. In addition, the rusted joint metaphor is <name>Normative References</name>
originally due to Adam Langley. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
</t> .2119.xml"/>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
</middle> .5246.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6347.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.7301.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8446.xml"/>
</references>
<back> <section anchor="Acknowledgments" numbered="false" toc="default">
<references title="Normative References"> <name>Acknowledgments</name>
&RFC2119; <t>
&RFC5246; The author would like to thank <contact fullname="Adam Langley"/>, <contact
&RFC6347; fullname="Nick Harper"/>, and <contact fullname="Steven Valdez"/> for their
&RFC7301; feedback and suggestions. In addition, the rusted joint metaphor is originally
&RFC8174; due to <contact fullname="Adam Langley"/>.
&RFC8446; </t>
</references> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 40 change blocks. 
445 lines changed or deleted 802 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/