Original text:
along with the new ClientHello.  For instance, if the client sends ClientHello1, its binder will be computed over: <del> Where Truncate() removes the binders list from the ClientHello. </del>  If the server responds with a HelloRetryRequest and the client then sends ClientHello2, its binder will be computed over: hash computations.  Note that in the first flight, Truncate(ClientHello1) is hashed directly, but in the second flight, ClientHello1 is hashed and then reinjected as a "message_hash" <del> message, as described in the-transcript-hash. </del>  4.2.11.3.

Reviewer comments:
The function is defined using a function . URL This is presumably the KDF hash of the cipher suite, but this doesn't seem to be written down anywhere. The Key Schedule section says: URL I can't find corresponding text in the various other calls. We could define this globally in the Transcript Hash section, and indeed that fits with the claim that "In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash." But then we have another problem... The PSK binder is also defined in terms of Transcript-Hash. Like the other text, it does not define what Hash is. URL But the default definition doesn't work for the client, in two different ways: At the first ClientHello, the cipher suite hash algorithm isn't even known yet, so we cannot possibly use that one. At the second ClientHello, we have a cipher suite hash algorithm, but it may not necessarily match the PSK's one. To keep all everything injective, both need to be the PSK hash. Though this results in another subtlety which, while not ambiguous, maybe we should change: At the second ClientHello, there are two uses of Hash. There's the overall hash, which is stuck being the PSK one, and there's the funny . That one being the PSK's hash breaks the whole notion of the transcript being this append-only thing and is a huge pain. To compensate, we allowed the second ClientHello to . That works, but it's a pretty weird edge case and easily a source of bugs. What if we changed it to be the negotiated hash? It won't affect interop, since this PSK is guaranteed not to be negotiated. The client may as well fill in all zeros for the binder. It's also still injective, as long as everyone agrees that's the one we use. The transcript includes an unhashed HelloRetryRequest immediately after messagehash, so that fixes the choice of hash. (Plus we only have two hashes right now and they're different sizes...)

Revised text:
along with the new ClientHello.  For instance, if the client sends ClientHello1, its binder will be computed over:  <ins> Where Truncate() removes the binders list from the ClientHello.  Note that this hash will be computed using the hash associated with the PSK, as the client does not know which cipher suite the server will select. </ins> If the server responds with a HelloRetryRequest and the client then sends ClientHello2, its binder will be computed over: hash computations.  Note that in the first flight, Truncate(ClientHello1) is hashed directly, but in the second flight, ClientHello1 is hashed and then reinjected as a "message_hash"  <ins> message, as described in the-transcript-hash.  Note that the "message_hash" will be hashed with the negotiated function, which may or may match the hash associated with the PSK.  This is consistent with how the transcript is calculated for the rest of the handshake. </ins> 4.2.11.3.