Draft: draft-ietf-tls-tls13

Commentary: 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 can not 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  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  ) .
Paragraph (version A):
A list of offered KeyShareEntry values in descending order of
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.
Paragraph (version B):
A list of offered KeyShareEntry values in descending order of
client preference.
Paragraph (version B):
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.
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", "key_update", and
"message_hash" 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_RESERVED", "encrypted_extensions",
"end_of_early_data", "key_update", and "message_hash" values.