Draft: draft-ietf-tls-tls13

Commentary: server to just store H(CH1 ) when doing  . PTAL 
 Seems reasonable . Still feels like a bit of a hack , though is better than having to ship the entire hash state in the HRR . 
 There is no good answer here , but this will do .
Paragraph (version A):
Allowing the server to offload state to the client, thus allowing
it to send a HelloRetryRequest without storing any state.  The
server does this by storing the serialized hash state in the
cookie (protected with some suitable integrity algorithm).
Paragraph (version B):
Allowing the server to offload state to the client, thus allowing
it to send a HelloRetryRequest without storing any state.  The
server does this by storing the hash of the ClientHello in the
HelloRetryRequest cookie (protected with some suitable integrity
algorithm).
Paragraph (version A):
The PSK binder value forms a binding between a PSK and the current
handshake, as well as between the handshake in which the PSK was
generated (if via a NewSessionTicket message) and the handshake where
it was used.  Each entry in the binders list is computed as an HMAC
over the portion of the ClientHello (including the handshake header)
up to and including the PreSharedKeyExtension.identities field.  That
is, it includes all of the ClientHello but not the binders list
itself.  The length fields for the message (including the overall
length, the length of the extensions block, and the length of the
"pre_shared_key" extension) are all set as if binders of the correct
lengths were present.
Paragraph (version B):
The PSK binder value forms a binding between a PSK and the current
handshake, as well as between the handshake in which the PSK was
generated (if via a NewSessionTicket message) and the handshake where
it was used.  Each entry in the binders list is computed as an HMAC
over a transcript hash (see the-transcript-hash) containing a partial
ClientHello up to and including the PreSharedKeyExtension.identities
field.  That is, it includes all of the ClientHello but not the
binders list itself.  The length fields for the message (including
the overall length, the length of the extensions block, and the
length of the "pre_shared_key" extension) are all set as if binders
of the correct lengths were present.
Paragraph (version A):
The full ClientHello is included in all other handshake hash
computations.
Paragraph (version B):
The full ClientHello is included in all other handshake hash
computations.  Note that in the first flight, ClientHello1[truncated]
is hashed directly, but in the second flight, it is hashed and then
reinjected as a "handshake_hash" message, as described in the-
transcript-hash.
Paragraph (version B):
A Handshake Context consisting of the set of messages to be
included in the transcript hash.
Paragraph (version A):
A MAC over the value Hash(Handshake Context + Certificate +
CertificateVerify) using a MAC key derived from the base key.
Paragraph (version A):
Because the CertificateVerify signs the Handshake Context +
Certificate and the Finished MACs the Handshake Context + Certificate
+ CertificateVerify, this is mostly equivalent to keeping a running
hash of the handshake messages (exactly so in the pure 1-RTT cases).
Note, however, that subsequent post-handshake authentications do not
include each other, just the messages through the end of the main
handshake.
Paragraph (version A):
In all cases, the handshake context is formed by concatenating the
indicated handshake messages, including the handshake message type
and length fields, but not including record layer headers.
Paragraph (version B):
A MAC over the value Transcript-Hash(Handshake Context,
Certificate, CertificateVerify) using a MAC key derived from the
base key.
Paragraph (version B):
Many of the cryptographic computations in TLS make use of a
transcript hash.  This value is computed by hashing the concatenation
of each included handshake message, including the handshake message
header carrying the handshake message type and length fields, but not
including record layer headers.  I.e.,
Paragraph (version B):
As an exception to this general rule, when the server responds to a
ClientHello with a HelloRetryRequest, the value of ClientHello1 is
replaced with a special synthetic handshake message of handshake type
"message_hash" containing Hash(ClientHello1).  I.e.,
Paragraph (version B):
The reason for this construction is to allow the server to do a
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).
Paragraph (version B):
In general, implementations can implement the transcript by keeping a
running transcript hash value based on the negotiated hash.  Note,
however, that subsequent post-handshake authentications do not
include each other, just the messages through the end of the main
handshake.
Paragraph (version A):
TLS HandshakeType Registry: Future values are allocated via
Standards Action RFC5226.  IANA [SHALL update/has updated] this
registry to rename item 4 from "NewSessionTicket" to
"new_session_ticket" and to add the "hello_retry_request",
"encrypted_extensions", "end_of_early_data", and "key_update"
values.
Paragraph (version B):
TLS HandshakeType Registry: Future values are allocated via
Standards Action RFC5226.  IANA [SHALL update/has updated] this
registry to rename item 4 from "NewSessionTicket" to
"new_session_ticket" and to add the "hello_retry_request",
"encrypted_extensions", "end_of_early_data", "key_update", and
"handshake_hash" values.