Change:
determined by the specified group and its corresponding definition. <del> The "extension_data" field of this extension contains a "KeyShare" value: </del> <ins> In the ClientHello message, the "extension_data" field of this extension contains a "KeyShareClientHello" value: </ins> <del> %%% Key Exchange Messages </del> <ins> %%% Key Exchange Messages struct { KeyShareEntry client_shares<0..2^16-1>; } KeyShareClientHello; </ins> A list of offered KeyShareEntry values in descending order of <del> client preference.  This vector MAY be empty if the client is requesting a HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a group offered in the "supported_groups" extension and MUST appear in the same order.  However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups.  Such a situation could arise if the most preferred groups are new and unlikely to be supported in enough places to make pregenerating key shares for them efficient. The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for. </del> <ins> client preference. </ins> <del> A single KeyShareEntry value that is in the same group as one of the client's shares. </del> <ins> This vector MAY be empty if the client is requesting a HelloRetryRequest.  Each KeyShareEntry value MUST correspond to a group offered in the "supported_groups" extension and MUST appear in the same order.  However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups.  Such a situation could arise if the most preferred groups are new and unlikely to be supported in enough places to make pregenerating key shares for them efficient. </ins> Clients can offer an arbitrary number of KeyShareEntry values, each representing a single set of key exchange parameters.  For instance,

Discussion:
I tend to narrow things from the right....
Programmer habits maybe, for me a "FooTest" is a specialization of "Test", so the current "KeyShareServerHello" looks like a specialization of "ServerHello" to me. It's a minor thing though.
Fair enough, but my habit is the opposite. :)
The text refers to helloretryrequest (e.g. in IANA considerations), but the HandshakeType enum refers to helloretryrequestRESERVED. Should something be said about Server Hello being able to modify ? Should something be said about rejecting handshake messages with ? (The current seems to suggest that the wire can really contain 6.)
My syntax validator also detects this error. We need to fix this.
I guess that it is hard to express a nested . So, it seems to me that a comment is reasonable:
That comment is not easy to parse for a machine :/ (btw, the comment is for the serverhello case, not clienthello). is only defined for enumerations, so we cannot do something like: (and even the above is not accurate since interpretation of random depends on the supportedextensions value.) Maybe something like: with the intention that ServerHelloParameters is populated while preparsing the SH message (prescan for supportedversions, detect HRR vs normal SH based on Random). This is inspired by the SecurityParameters type in RFC 5246.
LGTM. As a nitpick, maybe name it "ServerHelloKeyShare" instead of "KeyShareServerHello" (likewise for CH and HRR).