Draft: draft-ietf-tls-tls13

Commentary: This is definitely an improvement , but I think that it covers more changes than are absolutely necessary . 
 Can you explain what you mean with your overall comment ? 
 There are a few things in here that were n't strictly necessary . Mostly good things that we agreed to elsewhere . Like extensions in ServerConfiguration . 
 Do you think I should break this up ? 
  , I just wanted to flag it so that other reviewers would n't miss it . 
 In , suggests that the EncryptedExtensions message from the client should be optional . I 'd rather make it mandatory and simply carry the extra bits if it happens to be empty . The fewer optional parts the better . 
 The server - side one is optional , but the client - side one in that PR is n't . Consistency , either way , is probably a good idea . That said , I agree with your assessment . All usually needed handshake messages should probably be mandatory , with empty fields if not needed . This seems like a good idea to reduce risk potential issues from unneeded complexity . I see you also filed issue , which is another straightforward way to reduce complexity here . Also , turning ServerKeyShare into an extension to stick directly into ServerHello , as has been done already on the client - side , could simplify things a bit as well . ( Edit : I just filed issue for the last bit ) 
 Yes , this is just pilot error . They should all be mandatory . ,   wrote : 
 This should be done now . 
 They always appear together anyway . Having them independently optional risks errors . And combining them will save a few bytes from the handshake . The separation might have been nice in a past where static ( EC)DH cipher suites were in use , but I do n't see any way of TLS 1.3 supporting those modes in the future once we accept . 
 Ilari notes : 
 Ilari 's point is quite a good one , and unless you can elaborate on a known risk that 's particularly important , I do n't see it outweighing the need to touch this area . I think  , CertificateVerify , & Finished all need to be separate , because the latter two each depend on a hash of the session prior to it and I think the safest route is to just keep this design as - is . Handshake messages are coalesced into a single record , so merging two only saves 4 bytes , which I do n't think is worth worrying about once per handshake . 
 I think the conclusion is that this was a bad idea .
Paragraph (version A):
During an initial handshake, the server can provide a
ServerConfiguration message containing a long-term (EC)DH share.  On
future connections, the client can indicate to the server that it
knows the server's configuration and if that configuration is valid
the server can omit both the Certificate or CertificateVerify message
(provided that a new configuration is not supplied in this
handshake).
Paragraph (version A):
When a known configuration is used, the server's long-term DHE key is
combined with the client's ClientKeyShare to produce SS.  ES is
computed as above.  This optimization allows the server to amortize
the transmission of these messages and the server's signature over
multiple handshakes, thus reducing the server's computational cost
for cipher suites where signatures are slower than key agreement,
principally RSA signatures paired with ECDHE.
Paragraph (version A):
When a cached ServerConfiguration is used, the client can also send
application data as well as its Certificate and CertificateVerify (if
client authentication is requested) on its first flight, thus
reducing handshake latency, as shown below.
Paragraph (version B):
TLS 1.3 supports a "0-RTT" mode in which the client can send
application data as well as its Certificate and CertificateVerify (if
client authentication is requested) on its first flight, thus
reducing handshake latency.  In order to enable this functionality,
the server provides a ServerConfiguration message containing a long-
term (EC)DH share.  On future connections, the client uses that share
to encrypt the first-flight data.
Paragraph (version A):
Shortening the handshake because the certificate may be large.
Paragraph (version A):
Reducing cryptographic burden on the server if the server has an
RSA certificate, as well as on the client if the server has an
ECDSA certificate.
Paragraph (version A):
An opaque label for the configuration in question.
Paragraph (version A):
A client which wishes to reuse a known configuration MAY supply a
single KnownConfigurationExtension value which indicates the known
configuration it desires to use.  It is a fatal error to supply more
than one extension.  A server which wishes to use the key replies
with an empty extension (i.e., with a length field of 0) in its
ServerHello.
Paragraph (version A):
When the client and server mutually agree upon a known configuration
via this mechanism, then the Static Secret (SS) is computed based on
the server's (EC)DHE key from the identified configuration and the
client's key found in the ClientKeyShare.  If no key from an
acceptable group is in the ClientKeyShare, the server MUST ignore the
"known_configuration" extension.  When this mechanism is used, the
server MUST NOT send a Certificate/CertificateVerify message unless
the ServerConfiguration message is also sent.
Paragraph (version A):
When the "known_configuration" data extension is in use, the
handshake hash is extended to include the server's configuration data
and certificate (see the-handshake-hash) so as to tightly bind them
together.
Paragraph (version A):
In cases where TLS clients have previously interacted with the server
and the server has supplied a known configuration, the client can
send application data and its Certificate/CertificateVerify messages
(if client authentication is required).  If the client opts to do so,
it MUST supply an Early Data Indication extension.  This technique
MUST only be used along with the "known_configuration" extension.
Paragraph (version A):
The type of early data that is being sent. "early_handshake" means
that only handshake data is being sent. "early_data" means that
only data is being sent. "early_handshake_and_data" means that
both are being sent.
Paragraph (version B):
In cases where TLS clients have previously interacted with the server
and the server has supplied a ServerConfiguration server-
configuration, the client can send application data and its
Certificate/CertificateVerify messages (if client authentication is
required).  If the client opts to do so, it MUST supply an Early Data
Indication extension.
Paragraph (version B):
The label for the configuration in question.
Paragraph (version B):
The cipher suite which the client is using to encrypt the early
data.
Paragraph (version B):
The extensions required to define the cryptographic configuration
for the clients early data (see below for details).
Paragraph (version B):
The type of early data that is being sent. "client_authentication"
means that only handshake data is being sent. "early_data" means
that only data is being sent. "client_authentication_and_data"
means that both are being sent.
Paragraph (version B):
Send the same cryptographic determining parameters (Section
cryptographic-determining-parameters) with the previous
connection.  If a 0-RTT handshake is being used with a PSK that
was negotiated via a non-PSK handshake, then the client MUST use
the same symmetric cipher parameters as were negotiated on that
handshake but with a PSK cipher suite.
Paragraph (version B):
Indicate the same parameters as the server indicated in that
connection.
Paragraph (version A):
The server MUST first validate that the client's
"known_configuration" extension is valid and that the client has
suppled a valid key share in the "client_key_shares" extension.  If
not, it MUST ignore the extension and discard the early handshake
data and early data.
Paragraph (version B):
The configuration_id matches a known server configuration.
Paragraph (version B):
The client's cryptographic determining parameters match the
parameters that the server has negotiated based on the rest of the
ClientHello.
Paragraph (version B):
If any of these checks fail, the server MUST NOT respond with the
extension and must discard all the remaining first flight data (thus
falling back to 1-RTT).
Paragraph (version B):
The cipher suite identifier.
Paragraph (version B):
If PSK is being used, the server's version of the PreSharedKey
extension (indicating the PSK the client is using).
Paragraph (version A):
The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except DH_anon and PSK), unless the KnownKeyExtension is used.
This message will always immediately follow either the
EncryptedExtensions message if one is sent or the ServerKeyShare
message.
Paragraph (version B):
The server MUST send a Certificate message whenever the agreed-
upon key exchange method uses certificates for authentication
(this includes all key exchange methods defined in this document
except DH_anon and PSK).  This message will always immediately
follow the EncryptedExtensions message.
Paragraph (version A):
The configuration identifier to be used with the known
configuration extension known-configuration-extension.
Paragraph (version B):
The configuration identifier to be used in 0-RTT mode.
Paragraph (version A):
Whether the client may send data in its first flight (see early-
data-indication).
Paragraph (version B):
This field is a placeholder for future extensions to the
ServerConfiguration format.
Paragraph (version B):
The semantics of this message are to establish a shared state between
the client and server for use with the "known_configuration"
extension with the key specified in key and with the handshake
parameters negotiated by this handshake.
Paragraph (version A):
This message is used to provide explicit proof that the server
possesses the private key corresponding to its certificate and
also provides integrity for the handshake up to this point.  This
message is only sent when the server is authenticated via a
certificate.  When sent, it MUST be the last server handshake
message prior to the Finished.
Paragraph (version B):
This message is used to provide explicit proof that the server
possesses the private key corresponding to its certificate and
also provides integrity for the handshake up to this point.  This
message is sent when the server is authenticated via a
certificate.  When sent, it MUST be the last server handshake
message prior to the Finished.
Paragraph (version A):
When the known_configuration extension is in use (known-
configuration-extension, this contains the concatenation of the
ServerConfiguration and Certificate messages from the handshake
where the configuration was established.  Note that this requires
the client and server to memorize these values.
Paragraph (version B):
When 0-RTT is in use (early-data-indication) this contains the
concatenation of the ServerConfiguration and Certificate messages
from the handshake where the configuration was established.  Note
that this requires the client and server to memorize these values.