Draft: draft-ietf-tls-tls13

Commentary: You addressed the main ambiguity in . This fixes a few remaining issues . An itemized list : " handshakefailure " alert is fatal note it must be appended , not just " used " , in the selectedgroup description ( just using instead of appending creates a downgrade attack due to lack of authentication for this message , as discussed previously ) clean up styling of variable names ; the dominant style uses no quotes around variable names , but quotes around enum values ( granted , this may not be the ideal style , but it is more or less consistently the case elsewhere in the document ) note that the same rule as ServerHello applies : no extensions the client did not offer first update text to deal with possibility of omitted extension minor wording simplification specify error to use if " MUST " fails ( could be a " SHOULD " error , here ) 
 Repushed commit with changes for comments . Changed description to not say used / amended , but rather describe what it actually represents directly : the group the server intends to negotiate and is requesting a retry for . ( we do n't need duplicated MUSTs here , and stating its actual meaning more explicitly is preferable ) Changed text wrt selected group as suggested . 
 Rebased on top of PR ( which still merges cleanly onto master , as of this moment ; this does too ) to avoid flip - flopping again on the omit vs. empty KeyShare for retry request .
Paragraph (version A):
Servers send this message in response to a ClientHello message
when it was able to find an acceptable set of algorithms and
groups that are mutually supported, but the client's KeyShare did
not contain an acceptable offer.  If it cannot find such a match,
it will respond with a "handshake_failure" alert.
Paragraph (version B):
Servers send this message in response to a ClientHello message
when it was able to find an acceptable set of algorithms and
groups that are mutually supported, but the client's KeyShare did
not contain an acceptable offer.  If it cannot find such a match,
it will respond with a fatal "handshake_failure" alert.
Paragraph (version A):
The group which the client MUST use for its new ClientHello.
Paragraph (version A):
The "server_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.
Paragraph (version A):
Upon receipt of a HelloRetryRequest, the client MUST first verify
that the "selected_group" field corresponds to a group which was
provided in the "supported_groups" extension in the original
ClientHello.  It MUST then verify that the "selected_group" field
does not correspond to a group which was provided in the "key_share"
extension in the original ClientHello.  If either of these checks
fails, then the client MUST abort the handshake with a fatal
"handshake_failure" alert.  Clients SHOULD also abort with
"handshake_failure" in response to any second HelloRetryRequest which
was sent in the same connection (i.e., where the ClientHello was
itself in response to a HelloRetryRequest).
Paragraph (version B):
The mutually supported group the server intends to negotiate and
is requesting a retried ClientHello/KeyShare for.
Paragraph (version B):
The server_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.
Paragraph (version B):
Upon receipt of a HelloRetryRequest, the client MUST first verify
that the selected_group field corresponds to a group which was
provided in the "supported_groups" extension in the original
ClientHello.  It MUST then verify that the selected_group field does
not correspond to a group which was provided in the "key_share"
extension in the original ClientHello.  If either of these checks
fails, then the client MUST abort the handshake with a fatal
"handshake_failure" alert.  Clients SHOULD also abort with
"handshake_failure" in response to any second HelloRetryRequest which
was sent in the same connection (i.e., where the ClientHello was
itself in response to a HelloRetryRequest).
Paragraph (version A):
Otherwise, the client MUST send a ClientHello with a new KeyShare
extension to the server.  The client MUST append a new KeyShareEntry
list which is consistent with the "selected_group" field to the
groups in its original KeyShare.
Paragraph (version A):
Upon re-sending the ClientHello and receiving the server's
ServerHello/KeyShare, the client MUST verify that the selected
CipherSuite and NamedGroup match that supplied in the
HelloRetryRequest.
Paragraph (version B):
Otherwise, the client MUST send a ClientHello with an updated
KeyShare extension to the server.  The client MUST append a new
KeyShareEntry for the group indicated in the selected_group field to
the groups in its original KeyShare.
Paragraph (version B):
Upon re-sending the ClientHello and receiving the server's
ServerHello/KeyShare, the client MUST verify that the selected
CipherSuite and NamedGroup match that supplied in the
HelloRetryRequest.  If either of these values differ, the client MUST
abort the connection with a fatal "handshake_failure" alert.