Visual RFC.
ALL RFCs / RFC 9846
Read the RFC ↗
RFC 9846 / MECHANISMS

Retry stays in the transcript

03

HelloRetryRequest changes the offered key share without erasing the first ClientHello from the authenticated history.

Related RFCs and changes

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

DIAGRAM§ 2.1 ↗
RFC 9846 · § 2.1EXAMPLE
3 / 3
Retry stays in the transcriptHelloRetryRequest changes the offered key share without erasing the first ClientHello from the authenticated history. Current state: Second ClientHello.Retry stays in the transcriptClientServerClientHello · share AHelloRetryRequestClientHello · share BFirst hello + retry remain in the transcript
03
Second ClientHello

Send the requested share; keep the initial exchange bound into the transcript.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

An unacceptable key share can trigger HelloRetryRequest.

  • An unacceptable key share can trigger HelloRetryRequest.
  • The client sends an appropriate new share in a second ClientHello.
  • The transcript incorporates the initial ClientHello and retry rather than resetting.
DETAILS

The illustration is schematic. Example values are illustrative; profiles and later security guidance can add requirements.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. The protected handshake
  2. Fresh key shares for each connection
  3. Retry stays in the transcript
  4. Update before key limits
  5. Early data still needs replay handling
RFC 9700 / CHAPTERS

Chapters

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

RFC status and corrections ↗