Draft: draft-ietf-tls-tls13

Commentary: client to implement because it knows what hash the server will select . Also clarify the language about HRR and Key Shares . 
 is this what you had in mind ? 
 I did consider bogus binders , but dropping seems more sensible , and it seems like the only impact of the bogus binder would be that if the server did n't follow a consistent rule , then you would get a handshake failure at the server . It 's not like it could pick them in any case . 
 ( Agreed . This version feels way less weird . ) 
 comments welcome
Paragraph (version A):
The server_version and extensions fields have the same meanings as
their corresponding values in the ServerHello.  The server SHOULD
send only the extensions necessary for the client to generate a
correct ClientHello pair.  As with ServerHello, a HelloRetryRequest
MUST NOT contain any extensions that were not first offered by the
client in its ClientHello, with the exception of optionally the
"cookie" (see cookie) extension.
Paragraph (version B):
The version, cipher_suite, and extensions fields have the same
meanings as their corresponding values in the ServerHello.  The
server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello pair.  As with ServerHello, a
HelloRetryRequest MUST NOT contain any extensions that were not first
offered by the client in its ClientHello, with the exception of
optionally the "cookie" (see cookie) extension.
Paragraph (version B):
In addition, in its updated ClientHello, the client SHOULD NOT offer
any pre-shared keys associated with a hash other than that of the
selected cipher suite.  This allows the client to avoid having to
compute partial hash transcripts for multiple hashes in the second
ClientHello.  A client which receives a cipher suite that was not
offered MUST abort the handshake.  Servers MUST ensure that they
negotiate the same cipher suite when receiving a conformant updated
ClientHello (if the server selects the cipher suite as the first step
in the negotiation, then this will happen automatically).  Upon
receiving the ServerHello, clients MUST check that the cipher suite
supplied in the ServerHello is the same as that in the
HelloRetryRequest and otherwise abort the handshake with an
"illegal_parameter" alert.
Paragraph (version A):
If using (EC)DHE key establishment, servers offer exactly one
KeyShareEntry in the ServerHello.  This value MUST correspond to the
KeyShareEntry value offered by the client that the server has
selected for the negotiated key exchange.  Servers MUST NOT send a
KeyShareEntry for any group not indicated in the "supported_groups"
extension and MUST NOT send a KeyShareEntry when using the "psk_ke"
PskKeyExchangeMode.  If a HelloRetryRequest was received by the
client, the client MUST verify that the selected NamedGroup matches
one that the client sent in its supported_groups extension and MUST
abort the handshake with an "illegal_parameter" alert otherwise.
Paragraph (version B):
If using (EC)DHE key establishment, servers offer exactly one
KeyShareEntry in the ServerHello.  This value MUST correspond to the
KeyShareEntry value offered by the client that the server has
selected for the negotiated key exchange.  Servers MUST NOT send a
KeyShareEntry for any group not indicated in the "supported_groups"
extension and MUST NOT send a KeyShareEntry when using the "psk_ke"
PskKeyExchangeMode.  If a HelloRetryRequest was received by the
client, the client MUST verify that the selected NamedGroup in the
ServerHello is the same as that in the HelloRetryRequest.  If this
check fails, the client MUST abort the handshake with an
"illegal_parameter" alert.