Draft: draft-ietf-tls-rfc8446bis

Commentary: The function is defined using a function . This is presumably the KDF hash of the cipher suite , but this does n't seem to be written down anywhere . The Key Schedule section says : I ca n'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 . But the default definition does n't work for the client , in two different ways : At the first ClientHello , the cipher suite hash algorithm is n't even known yet , so we can not 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 wo n'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 ... )
Paragraph (version A):
Where Truncate() removes the binders list from the ClientHello.
Paragraph (version B):
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.
Paragraph (version A):
The full ClientHello1/ClientHello2 is included in all other handshake
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"
message, as described in the-transcript-hash.
Paragraph (version B):
The full ClientHello1/ClientHello2 is included in all other handshake
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"
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.