Draft: draft-ietf-tls-tls13

Commentary: At the interim we agreed to remove renegotiation
Paragraph (version B):
Remove renegotiation.
Paragraph (version A):
Each connection state contains a sequence number, which is
maintained separately for read and write states.  The sequence
number MUST be set to zero whenever a connection state is made the
active state.  Sequence numbers are of type uint64 and may not
exceed 2^64-1.  Sequence numbers do not wrap.  If a TLS
implementation would need to wrap a sequence number, it must
renegotiate instead.  A sequence number is incremented after each
record: specifically, the first record transmitted under a
particular connection state MUST use sequence number 0.
Paragraph (version B):
Each connection state contains a sequence number, which is
maintained separately for read and write states.  The sequence
number MUST be set to zero whenever a connection state is made the
active state.  Sequence numbers are of type uint64 and may not
exceed 2^64-1.  Sequence numbers do not wrap.  If a TLS
implementation would need to wrap a sequence number, it must
terminate the connection.  A sequence number is incremented after
each record: specifically, the first record transmitted under a
particular connection state MUST use sequence number 0.
Paragraph (version A):
Note: Data of different TLS record layer content types MAY be
interleaved.  Application data is generally of lower precedence for
transmission than other content types.  However, records MUST be
delivered to the network in the same order as they are protected by
the record layer.  Recipients MUST receive and process interleaved
application layer traffic during handshakes subsequent to the first
one on a connection.
Paragraph (version A):
Sent by the client in response to a hello request or by the server
in response to a client hello after initial handshaking.  Either
of these would normally lead to renegotiation; when that is not
appropriate, the recipient should respond with this alert.  At
that point, the original requester can decide whether to proceed
with the connection.  One case where this would be appropriate is
where a server has spawned a process to satisfy a request; the
process might receive security parameters (key length,
authentication, etc.) at startup, and it might be difficult to
communicate changes to these parameters after that point.  This
message is always a warning.
Paragraph (version B):
Sent by the client in response to a hello request or by the server
in response to a client hello after initial handshaking.  Versions
of TLS prior to TLS 1.3 supported renegotiation of a previously
established connection; TLS 1.3 removes this feature.  This
message is always fatal.
Paragraph (version A):
The handshake protocol messages are presented below in the order they
MUST be sent; sending handshake messages in an unexpected order
results in a fatal error.  Unneeded handshake messages can be
omitted, however.  The one message that is not bound by these
ordering rules is the HelloRequest message, which can be sent at any
time, but which SHOULD be ignored by the client if it arrives in the
middle of a handshake.
Paragraph (version B):
The handshake protocol messages are presented below in the order they
MUST be sent; sending handshake messages in an unexpected order
results in a fatal error.  Unneeded handshake messages can be
omitted, however.
Paragraph (version A):
The HelloRequest message MAY be sent by the server at any time.
Paragraph (version A):
HelloRequest is a simple notification that the client should begin
the negotiation process anew.  In response, the client should send
a ClientHello message when convenient.  This message is not
intended to establish which side is the client or server but
merely to initiate a new negotiation.  Servers SHOULD NOT send a
HelloRequest immediately upon the client's initial connection.  It
is the client's job to send a ClientHello at that time.
Paragraph (version A):
This message will be ignored by the client if the client is
currently negotiating a session.  This message MAY be ignored by
the client if it does not wish to renegotiate a session, or the
client may, if it wishes, respond with a no_renegotiation alert.
Since handshake messages are intended to have transmission
precedence over application data, it is expected that the
negotiation will begin before no more than a few records are
received from the client.  If the server sends a HelloRequest but
does not receive a ClientHello in response, it may close the
connection with a fatal alert.
Paragraph (version A):
After sending a HelloRequest, servers SHOULD NOT repeat the
request until the subsequent handshake negotiation is complete.
Paragraph (version A):
This message MUST NOT be included in the message hashes that are
maintained throughout the handshake and used in the Finished messages
and the certificate verify message.
Paragraph (version A):
When a client first connects to a server, it is required to send
the ClientHello as its first message.  The client can also send a
ClientHello in response to a HelloRequest or on its own initiative
in order to renegotiate the security parameters in an existing
connection.  Finally, the client will send a ClientHello when the
server has responded to its ClientHello with a ServerHello that
selects cryptographic parameters that don't match the client's
ClientKeyShare.  In that case, the client MUST send the same
ClientHello (without modification) along with the new
ClientKeyShare.
Paragraph (version B):
When a client first connects to a server, it is required to send
the ClientHello as its first message.  The client will also send a
ClientHello when the server has responded to its ClientHello with
a ServerHello that selects cryptographic parameters that don't
match the client's ClientKeyShare.  In that case, the client MUST
send the same ClientHello (without modification) along with the
new ClientKeyShare.  If a server receives a ClientHello at any
other time, it MUST send a fatal no_renegotiation alert.
Paragraph (version A):
After sending the ClientHello message, the client waits for a
ServerHello message.  Any handshake message returned by the server,
except for a HelloRequest, is treated as a fatal error.
Paragraph (version B):
After sending the ClientHello message, the client waits for a
ServerHello or HelloVerifyRequest message.