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

Vary probes while preserving valid message structure

04

GREASE tests unknown-value tolerance inside otherwise valid messages. Random choices do not waive TLS syntax or extension rules.

DIAGRAMRead RFC section 5 ↗
RFC 8701 · § 5EXAMPLE
3 / 3
Vary probes while preserving valid message structureThree construction scenes. First, an invalid extension block repeats type 0x0A0A with different payload lengths and stops before sending. Second, distinct types 0x0A0A and 0x1A1A pass only the uniqueness check. Third, chosen example connections vary probe values while keeping the probe position fixed. Random values are a SHOULD, balanced with a SHOULD for diversity and determinism. These examples are not a random generator, required cadence or complete TLS message validation.Chosen connections · same probe positionConnection A0x0A0Aknown suiteConnection B0x2A2Aknown suiteSHOULD select random valuesSHOULD balance diversity with determinism
03
Balance diversity and reproducibility.

Across chosen example connections, distinct values change while the probe slot stays fixed. Random selection is SHOULD, not MUST, and no exact cadence is mandated.

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

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

Vary the probe; preserve the protocol.

  • Implementations advertising GREASE SHOULD select values at random, so peers learn to ignore all unknown values rather than a fixed blacklist.
  • Implementations MUST honor protocol specifications. The same extension type cannot appear twice in one extension block (RFC 8446 section 4.2).
  • Implementations SHOULD balance diversity with determinism; changing positions on every connection can make a broken peer fail only probabilistically.
DETAILS

Chosen values and positions here are worked examples, not a random-number generator or mandated ordering. A release can keep positions stable to make failures reproducible while varying values. Repeating a type is different from using two distinct GREASE extension types. No malformed payload is justified by GREASE.

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 ↗