Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions draft-ietf-tls-rfc8446bis.md
Original file line number Diff line number Diff line change
Expand Up @@ -2995,13 +2995,16 @@ stateless HelloRetryRequest by storing just the hash of ClientHello1
in the cookie, rather than requiring it to export the entire intermediate
hash state (see {{cookie}}).

For concreteness, the transcript hash is always taken from the
following sequence of handshake messages, starting at the first
ClientHello and including only those messages that were sent:
ClientHello, HelloRetryRequest, ClientHello, ServerHello,
When a range of messages is specified with "...", the transcript hash
is taken from the sequence of handshake messages that were sent or received
during the main handshake, starting and ending at the specified messages.
In this document, it is taken from the following sequence of handshake
messages: ClientHello, HelloRetryRequest, ClientHello, ServerHello,
EncryptedExtensions, server CertificateRequest, server Certificate,
server CertificateVerify, server Finished, EndOfEarlyData, client
Certificate, client CertificateVerify, and client Finished.
Certificate, client CertificateVerify, and client Finished. TLS extensions may
add or remove messages, in which case the transcript hash will reflect the
modified sequence.

In general, implementations can implement the transcript by keeping a
running transcript hash value based on the negotiated hash. Note,
Expand Down