Draft: draft-ietf-tls-tls13

Commentary: key changes happen at Handshake boundaries . Suggested by   
 I have one here , that could be a start : Also this is assuming PR is accepted ( becomes a message ) 
 Merged .
Paragraph (version B):
Change end_of_early_data to be a handshake message (*).
Paragraph (version A):
0-RTT messages sent in the first flight have the same content types
as their corresponding messages sent in other flights (handshake,
application_data, and alert respectively) but are protected under
different keys.  After receiving the server's Finished message, if
the server has accepted early data, an "end_of_early_data" alert of
type "warning" MUST be sent to indicate the key change.  This message
will be encrypted with the 0-RTT traffic keys.
Paragraph (version B):
0-RTT messages sent in the first flight have the same content types
as their corresponding messages sent in other flights (handshake,
application_data, and alert respectively) but are protected under
different keys.  After receiving the server's Finished message, if
the server has accepted early data, an EndOfEarlyData message will be
sent to indicate the key change.  This message will be encrypted with
the 0-RTT traffic keys.
Paragraph (version A):
Clients are permitted to "stream" 0-RTT data until they receive the
server's Finished, only then sending the "end_of_early_data" alert.
In order to avoid deadlock, when accepting "early_data", servers MUST
process the client's ClientHello and then immediately send the
ServerHello, rather than waiting for the client's "end_of_early_data"
alert.
Paragraph (version B):
Clients are permitted to "stream" 0-RTT data until they receive the
server's Finished, only then sending the EndOfEarlyData message.  In
order to avoid deadlock, when accepting "early_data", servers MUST
process the client's ClientHello and then immediately send the
ServerHello, rather than waiting for the client's EndOfEarlyData
message.
Paragraph (version B):
The EndOfEarlyData message is sent by the client to indicate that all
0-RTT application_data messages have been transmitted (or none will
be sent at all) and that the following records are protected under
handshake traffic keys.  Servers MUST NOT send this message and
clients receiving it MUST terminate the connection with an
"unexpected_message" alert.
Paragraph (version A):
This alert is sent by the client to indicate that all 0-RTT
application_data messages have been transmitted (or none will be
sent at all) and that the following records are protected under
handshake traffic keys.  This alert MUST be at the warning level.
Servers MUST NOT send this alert and clients receiving it MUST
terminate the connection with an "unexpected_message" alert.
Paragraph (version A):
TLS Alert Registry: Future values are allocated via Standards
Action RFC5226.  IANA [SHALL update/has updated] this registry to
include values for "end_of_early_data", "missing_extension", and
"certificate_required".
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", and "key_update" values.
Paragraph (version B):
TLS Alert Registry: Future values are allocated via Standards
Action RFC5226.  IANA [SHALL update/has updated] this registry to
include values for "missing_extension" and "certificate_required".
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", and "key_update"
values.