Visual RFC.
ALL RFCs / RFC 8701
Read the RFC ↗
RFC 8701 / TLS EXTENSIBILITY

Expose intolerance and reject invalid selections

05

GREASE should reveal extensibility bugs rather than hide them behind automatic fallback. Valid negotiation still needs a real common parameter.

DIAGRAMRead RFC section 7 ↗
RFC 8701 · § 7EXAMPLE
4 / 4
Expose intolerance and reject invalid selectionsFour separate failure cases. The client MUST reject a server-selected GREASE value. An offer containing only GREASE leaves no known suite, so parameter negotiation fails. A broken server rejects an unknown offer before considering the real candidate, exposing an extensibility bug. A fallback retry with GREASE removed is stopped as a SHOULD NOT recommendation, not a MUST NOT rule. GREASE does not authenticate a peer, and non-random choices may enable fingerprinting.ClientServerAfter connection failureretry with GREASE removedSHOULD NOT hide the failureRecommendation, not a MUST NOT rule
04
Do not hide the failure by stripping GREASE.

Retrying with GREASE disabled is SHOULD NOT. Such retries can conceal the problem. This recommendation is distinct from mandatory rejection of a negotiated GREASE value.

Source for this drawing: RFC 8701 · Read RFC section 7 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A seal answers a specific question.

A certificate or signature supports particular checks about a key or message. It does not automatically prove that every claim or sender is trustworthy.

Helpful first, if these ideas are unfamiliar

RFC 8446 TLS 1.3 RFC 5246 TLS 1.2

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Ignore unknown offers; fail invalid selections.

  • A client MUST fail when the server negotiates GREASE, including the ServerHello cipher_suite illustrated here. The client may reuse ordinary unknown-selection rejection logic.
  • If no known parameter remains after ignoring unknown offers, parameter negotiation fails. GREASE does not create compatibility.
  • Implementations SHOULD NOT retry with GREASE disabled on connection failure. That fallback would mask extensibility failures; it is not a MUST NOT rule.
DETAILS

The source also covers rejected server-selected GREASE versions, extensions, groups and signature algorithms in the specified messages. A buggy peer rejecting unknown offers is the defect being exposed, not desired behavior. GREASE is not authentication, encryption or a guarantee of future compatibility. Non-random choices can enable implementation or user fingerprinting; randomization does not promise anonymity.

Read the RFC section ↗

All chapters in RFC 8701

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗