Draft: draft-ietf-tls-tls13

Commentary: Integration of semi - ephemeral DH proposal . Add initial 0 - RTT support Remove resumption and replace with PSK + tickets Move ClientKeyShare into an extension . Move to HKDF 
 PR for posterity 
 This accidentally reverted 
 Yes , I see what happened here . git pilot error . Here 's the commits that were in master but not WIPdraft07 . I 'm just going to cherry - pick that change back . please let me know if I lost anything else . commit Merge : Author : ekr Date : Sat Jul 4 15:35:31 2015 -0700 commit Author :    : Sat Jul 4 15:30:55 2015 -0400 
 I think it was just that one last commit . The immediately prior commit was n't reverted . I think it 's fine now .  has entirely too many footguns . :/ 
 You also introduced a couple of typos , by the way . I tacked fixes for them onto my current trivial fixes PR :
Paragraph (version B):
draft-07 - Integration of semi-ephemeral DH proposal.
Paragraph (version B):
Move ClientKeyShare into an extension.
Paragraph (version A):
This document and the TLS protocol itself are based on the SSL 3.0
Protocol Specification as published by Netscape.  The differences
between this protocol and SSL 3.0 are not dramatic, but they are
significant enough that the various versions of TLS and SSL 3.0 do
not interoperate (although each protocol incorporates a mechanism by
which an implementation can back down to prior versions).  This
document is intended primarily for readers who will be implementing
the protocol and for those doing cryptographic analysis of it.  The
specification has been written with this in mind, and it is intended
to reflect the needs of those two groups.  For that reason, many of
the algorithm-dependent data structures and rules are included in the
body of the text (as opposed to in an appendix), providing easier
access to them.
Paragraph (version B):
This document and the TLS protocol itself have evolved from the SSL
between this protocol and previosu versions are significant enough
that the various versions of TLS and SSL 3.0 do not interoperate
(although each protocol incorporates a mechanism by which an
implementation can back down to prior versions).  This document is
intended primarily for readers who will be implementing the protocol
and for those doing cryptographic analysis of it.  The specification
has been written with this in mind, and it is intended to reflect the
needs of those two groups.  For that reason, many of the algorithm-
dependent data structures and rules are included in the body of the
text (as opposed to in an appendix), providing easier access to them.
Paragraph (version A):
A construction is required to do expansion of secrets into blocks of
data for the purposes of key generation or validation.  This
pseudorandom function (PRF) takes as input a secret, a seed, and an
identifying label and produces an output of arbitrary length.
Paragraph (version A):
In this section, we define one PRF, based on HMAC RFC2104.  This PRF
with the SHA-256 hash function is used for all cipher suites defined
in this document and in TLS documents published prior to this
document when TLS 1.2 or later is negotiated.  New cipher suites MUST
explicitly specify a PRF and, in general, SHOULD use the TLS PRF with
SHA-256 or a stronger standard hash function.
Paragraph (version A):
where + indicates concatenation.
Paragraph (version A):
P_hash can be iterated as many times as necessary to produce the
required quantity of data.  For example, if P_SHA256 is being used to
create 80 bytes of data, it will have to be iterated three times
(through A(3)), creating 96 bytes of output data; the last 16 bytes
of the final iteration will then be discarded, leaving 80 bytes of
output data.
Paragraph (version A):
An algorithm used to generate keys from the master secret (see
HMAC and key-calculation).
Paragraph (version B):
An algorithm used to generate keys from the appropriate secret
(see key-schedule and traffic-key-calculation).
Paragraph (version A):
A 48-byte secret shared between the two peers in the connection
and used to generate keys for protecting the handshake.
Paragraph (version A):
A 48-byte secret shared between the two peers in the connection
and used to generate keys for protecting application data.
Paragraph (version B):
A 48-byte secret shared between the two peers in the connection
and used to generate keys for protecting data.
Paragraph (version A):
The client write parameters are used by the server when receiving and
processing records and vice versa.  The algorithm used for generating
these items from the security parameters is described in key-
calculation.
Paragraph (version B):
The client write parameters are used by the server when receiving and
processing records and vice versa.  The algorithm used for generating
these items from the security parameters is described in traffic-key-
calculation.
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 MUST 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 B):
Each connection state contains a sequence number, which is
maintained separately for read and write states.  The sequence
number is set to zero at the beginning of a connection and
incremented by one thereafter.  Sequence numbers are of type
uint64 and MUST 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.
NOTE: This is a change from previous versions of TLS, where
sequence numbers were reset whenever keys were changed.
Paragraph (version A):
The record_version field is identical to
TLSPlaintext.record_version and is always { 3, 1 }.
Paragraph (version B):
The record_version field is identical to
TLSPlaintext.record_version and is always { 3, 1 }.  Note that the
handshake protocol including the ClientHello and ServerHello
messages authenticates the protocol version, so this value is
redundant.
Paragraph (version A):
The master secret is expanded into a sequence of secure bytes, which
is then split to a client write encryption key and a server write
encryption key.  Each of these is generated from the byte sequence in
that order.  Unused values are empty.
Paragraph (version A):
When keys are generated, the current master secret (MS) is used as an
entropy source.  For handshake records, this means the
hs_master_secret.  For application data records, this means the
regular master_secret.
Paragraph (version A):
An arbitrary byte sequence chosen by the server to identify an
active or resumable session state.
Paragraph (version A):
48-byte secret shared between the client and server.
Paragraph (version A):
A flag indicating whether the session can be used to initiate new
connections.
Paragraph (version A):
These items are then used to create security parameters for use by
the record layer when protecting application data.  Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
Paragraph (version B):
a secret shared between the client and server that can be used as
a PSK in future connections.
Paragraph (version B):
These items are then used to create security parameters for use by
the record layer when protecting application data.  Many connections
can be instantiated using the same session using a PSK established in
an initial handshake.
Paragraph (version A):
Either party MAY initiate a close by sending a "close_notify" alert.
Any data received after a closure alert is ignored.
Paragraph (version B):
Either party MAY initiate a close by sending a "close_notify" alert.
Any data received after a closure alert is ignored.  If a transport-
level close is received prior to a close_notify, the receiver cannot
know that all the data that was sent has been received.
Paragraph (version A):
The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS record
layer.  When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and use public-key encryption
techniques to generate shared secrets.
Paragraph (version A):
Exchange hello messages to agree on a protocol version,
algorithms, exchange random values, and check for session
resumption.
Paragraph (version A):
Exchange the necessary cryptographic parameters to allow the
client and server to agree on a premaster secret.
Paragraph (version A):
Exchange certificates and cryptographic information to allow the
client and server to authenticate themselves.
Paragraph (version A):
Generate a master secret from the premaster secret and exchanged
random values.
Paragraph (version A):
Provide security parameters to the record layer.
Paragraph (version A):
Allow the client and server to verify that their peer has
calculated the same security parameters and that the handshake
occurred without tampering by an attacker.
Paragraph (version A):
Note that higher layers should not be overly reliant on whether TLS
always negotiates the strongest possible connection between two
peers.  There are a number of ways in which a man-in-the-middle
attacker can attempt to make two entities drop down to the least
secure method they support.  The protocol has been designed to
minimize this risk, but there are still attacks available.  For
example, an attacker could block access to the port a secure service
runs on or attempt to get the peers to negotiate an unauthenticated
connection.  The fundamental rule is that higher levels must be
cognizant of what their security requirements are and never transmit
information over a channel less secure than what they require.  The
TLS protocol is secure in that any cipher suite offers its promised
level of security: if you negotiate AES-GCM GCM with a 255-bit ECDHE
key exchange with a host whose certificate chain you have verified,
you can expect that to be reasonably secure.
Paragraph (version A):
These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a ClientHello message which
contains a random nonce (ClientHello.random), its preferences for
Protocol Version, Cipher Suite, and a variety of extensions.  In the
same flight, it sends a ClientKeyShare message which contains its
share of the parameters for key agreement for some set of expected
server parameters (DHE/ECDHE groups, etc.).
Paragraph (version A):
If the client has provided a ClientKeyShare with an appropriate set
of keying material, the server responds to the ClientHello with a
ServerHello message.  The ServerHello contains the server's nonce
(ServerHello.random), the server's choice of the Protocol Version,
Session ID and Cipher Suite, and the server's response to the
extensions the client offered.
Paragraph (version A):
The server can then generate its own keying material share and send a
ServerKeyShare message which contains its share of the parameters for
the key agreement.  The server can now compute the shared secret (the
premaster secret).  At this point, the server starts encrypting all
remaining handshake traffic with the negotiated cipher suite using a
key derived from the premaster secret (via the "handshake master
secret").  The remainder of the server's handshake messages will be
encrypted using that key.
Paragraph (version A):
Once the client receives the ServerKeyShare, it can also compute the
premaster secret and decrypt the server's remaining handshake
messages.  The client generates its own sending keys based on the
premaster secret and will encrypt the remainder of its handshake
messages using those keys and the newly established cipher suite.  If
the server has sent a CertificateRequest message, the client MUST
send the Certificate message, though it may contain zero
certificates.  If the client has sent a certificate, a digitally-
signed CertificateVerify message is sent to explicitly verify
possession of the private key in the certificate.  Finally, the
client sends the Finished message.
Paragraph (version B):
The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS record
layer.  When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and establish shared secret
keying material.
Paragraph (version B):
Diffie-Hellman (of both the finite field and elliptic curve
varieties).
Paragraph (version B):
Which mode is used depends on the negotiated cipher suite.
Conceptually, the handshake establishes two secrets which are used to
derive all the keys.
Paragraph (version B):
Ephemeral Secret (ES): A secret which is derived from fresh (EC)DHE
shares for this connection.  Keying material derived from ES is
intended to be forward secure (with the exception of pre-shared key
only modes).
Paragraph (version B):
Static Secret (SS): A secret which may be derived from static or
semi-static keying material, such as a pre-shared key or the server's
semi-static (EC)DH share.
Paragraph (version B):
In some cases, as with the DH handshake shown in tls-full, these
secrets are the same, but having both allows for a uniform key
derivation scheme for all cipher modes.
Paragraph (version B):
The first message sent by the client is the ClientHello client-hello
which contains a random nonce (ClientHello.random), its offered
protocol version, cipher suite, and extensions, and one or more
Diffie-Hellman key shares in the ClientKeyShare extension client-key-
share.
Paragraph (version B):
At this point, the handshake is complete, and the client and server
may exchange application layer data.  Application data MUST NOT be
sent prior to sending the Finished message.  If client authentication
is requested, the server MUST NOT send application data before it
receives the client's Finished.
Paragraph (version A):
The client sends a ClientHello using the Session ID of the session to
be resumed.  The server then checks its session cache for a match.
If a match is found, and the server is willing to re-establish the
connection under the specified session state, it will send a
ServerHello with the same Session ID value.  At this point, both
client and server MUST proceed directly to sending Finished messages,
which are protected using handshake keys as described above, computed
using resumption premaster secret created in the first handshake as
the premaster secret.  Once the re-establishment is complete, the
client and server MAY begin to exchange application layer data, which
is protected using the application secrets (See flow chart below.)
If a Session ID match is not found, the server generates a new
session ID, and the TLS client and server perform a full handshake.
Paragraph (version A):
The TLS Handshake Protocol is one of the defined higher-level clients
of the TLS Record Protocol.  This protocol is used to negotiate the
secure attributes of a session.  Handshake messages are supplied to
the TLS record layer, where they are encapsulated within one or more
TLSPlaintext structures, which are processed and transmitted as
specified by the current active session state.
Paragraph (version B):
TLS also allows several optimized variants of the basic handshake, as
described below.
Paragraph (version B):
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 B):
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 B):
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):
Note: because sequence numbers continue to increment between the
initial (early) application data and the application data sent after
the handshake has complete, an attacker cannot remove early
application data messages.
Paragraph (version B):
IMPORTANT NOTE: The security properties for 0-RTT data (regardless of
the cipher suite) are weaker than those for other kinds of TLS data.
Specifically.
Paragraph (version B):
This data is not forward secure, because it is encrypted solely
with the server's semi-static (EC)DH share.
Paragraph (version B):
There are no guarantees of non-replay between connections.  Unless
the server takes special measures outside those provided by TLS
(See replay-properties), the server has no guarantee that the same
0-RTT data was not transmitted on multiple 0-RTT connections.
This is especially relevant if the data is authenticated either
with TLS client authentication or inside the application layer
protocol.  However, 0-RTT data cannot be duplicated within a
connection (i.e., the server will not process the same data twice
for the same connection) and also cannot be sent as if it were
ordinary TLS data.
Paragraph (version B):
If the server key is compromised, and client authentication is
used, then the attacker can impersonate the client to the server
(as it knows the traffic key).
Paragraph (version B):
Finally, TLS provides a pre-shared key (PSK) mode which allows a
client and server who share an existing secret (e.g., a key
established out of band) to establish a connection authenticated by
that key.  PSKs can also be established in a previous session and
then reused ("session resumption").  Once a handshake has completed,
the server can send the client a PSK identity which corresponds to a
key derived from the initial handshake (See new-session-ticket-
message).  The client can then use that PSK identity in future
handshakes to negotiate use of the PSK; if the server accepts it,
then the security context of the original connection is tied to the
new connection.  In TLS 1.2 and below, this functionality was
provided by "session resumption" and "session tickets" RFC5077.  Both
mechanisms are obsoleted in TLS 1.3.
Paragraph (version B):
PSK ciphersuites can either use PSK in combination with an (EC)DHE
exchange in order to provide forward secrecy in combination with
shared keys, or can use PSKs alone, at the cost of losing forward
secrecy.
Paragraph (version B):
Note that the client supplies a ClientKeyShare to the server as well,
which allows the server to decline resumption and fall back to a full
handshake.  However, because the server is authenticating via a PSK,
it does not send a Certificate or a CertificateVerify.  PSK-based
resumption cannot be used to provide a new ServerConfiguration.
Paragraph (version B):
The TLS Handshake Protocol is one of the defined higher-level clients
of the TLS Record Protocol.  This protocol is used to negotiate the
secure attributes of a session.  Handshake messages are supplied to
the TLS record layer, where they are encapsulated within one or more
TLSPlaintext or TLSCiphertext structures, which are processed and
transmitted as specified by the current active session state.
Paragraph (version A):
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 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) except including
a new ClientKeyShare.  [[OPEN ISSUE: New random values?  See:
https://github.com/tlswg/tls13-spec/issues/185]] If a server
receives a ClientHello at any other time, it MUST send a fatal
"no_renegotiation" alert.
Paragraph (version A):
Note: The ClientHello message includes a variable-length session
identifier.  If not empty, the value identifies a session between the
same client and server whose security parameters the client wishes to
reuse.  The session identifier MAY be from an earlier connection,
this connection, or from another currently active connection.  The
second option is useful if the client only wishes to update the
random structures and derived values of a connection, and the third
option makes it possible to establish several independent secure
connections without repeating the full handshake protocol.  These
independent connections may occur sequentially or simultaneously; a
SessionID becomes valid when the handshake negotiating it completes
with the exchange of Finished messages and persists until it is
removed due to aging or because a fatal error was encountered on a
connection associated with the session.  The actual contents of the
SessionID are defined by the server.
Paragraph (version A):
The cipher suite list, passed from the client to the server in the
ClientHello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first).  Each cipher suite defines a key
exchange algorithm, a record protection algorithm (including secret
key length) and a PRF.  The server will select a cipher suite or, if
no acceptable choices are presented, return a "handshake_failure"
alert and close the connection.  If the list contains cipher suites
the server does not recognize, support, or wish to use, the server
MUST ignore those cipher suites, and process the remaining ones as
usual.
Paragraph (version A):
The ID of a session the client wishes to use for this connection.
This field is empty if no session_id is available, or if the
client wishes to generate new security parameters.
Paragraph (version A):
This is a list of the cryptographic options supported by the
client, with the client's first preference first.  If the
session_id field is not empty (implying a session resumption
request), this vector MUST include at least the cipher_suite from
that session.  Values are defined in the-cipher-suite.
Paragraph (version B):
Versions of TLS prior to TLS 1.3 supported a session resumption
feature which has been merged with Pre-Shared Keys in this version
(see resumption-and-psk).  This field MUST be ignored by a server
negotiating TLS 1.3 and should be set as a zero length vector
(i.e., a single zero byte length field) by clients which do not
have a cached session_id set by a pre-TLS 1.3 server.
Paragraph (version B):
This is a list of the cryptographic options supported by the
client, with the client's first preference first.  Values are
defined in the-cipher-suite.
Paragraph (version A):
This message is always sent by the client.  It MUST immediately
follow the ClientHello message.  In backward compatibility mode
(see Section XXX) it will be included in the EarlyData extension
(early-data-extension) in the ClientHello.
Paragraph (version A):
This message contains the client's cryptographic parameters for
zero or more key establishment methods.
Paragraph (version A):
A list of ClientKeyShareOffer values.
Paragraph (version A):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
and the client's ClientKeyShare message was acceptable.  If the
client proposed groups are not acceptable by the server, it will
respond with an "insufficient_security" fatal alert.
Paragraph (version B):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
and the client's ClientKeyShare extension was acceptable.  If the
client proposed groups are not acceptable by the server, it will
respond with an "insufficient_security" fatal alert.
Paragraph (version A):
This is the identity of the session corresponding to this
connection.  If the ClientHello.session_id was non-empty, the
server will look in its session cache for a match.  If a match is
found and the server is willing to establish the new connection
using the specified session state, the server will respond with
the same value as was supplied by the client.  This indicates a
resumed session and dictates that the parties must proceed
directly to the Finished messages.  Otherwise, this field will
contain a different value identifying the new session.  The server
may return an empty session_id to indicate that the session will
not be cached and therefore cannot be resumed.  If a session is
resumed, it must be resumed using the same cipher suite it was
originally negotiated with.  Note that there is no requirement
that the server resume any session even if it had formerly
provided a session_id.  Clients MUST be prepared to do a full
negotiation -- including negotiating new cipher suites -- during
any handshake.
Paragraph (version A):
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites.  For resumed sessions, this field is
the value from the state of the session being resumed.
Paragraph (version A):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
but the client's ClientKeyShare message did not contain an
acceptable offer.  If it cannot find such a match, it will respond
with a "handshake_failure" alert.
Paragraph (version B):
The server will send this message in response to a ClientHello
message when it was able to find an acceptable set of algorithms
and groups that are mutually supported, but the client's
ClientKeyShare did not contain an acceptable offer.  If it cannot
find such a match, it will respond with a "handshake_failure"
alert.
Paragraph (version A):
The "server_version", "cipher_suite" and "extensions" fields have the
same meanings as their corresponding values in the ServerHello.  The
server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello/ClientKeyShare pair.
Paragraph (version A):
Upon receipt of a HelloRetryRequest, the client MUST send a new
ClientHello/ClientKeyShare pair to the server.  The ClientKeyShare
MUST contain both the groups in the original ClientKeyShare as well
as a ClientKeyShareOffer consistent with the "selected_group" field.
I.e., it MUST be a superset of the previous ClientKeyShareOffer.
Paragraph (version A):
Upon re-sending the ClientHello/ClientKeyShare and receiving the
server's ServerHello/ServerKeyShare, the client MUST verify that the
selected CipherSuite and NamedGroup match that supplied in the
HelloRetryRequest.
Paragraph (version B):
The "server_version", "cipher_suite" and "extensions" fields have the
same meanings as their corresponding values in the ServerHello.  The
server SHOULD send only the extensions necessary for the client to
generate a correct ClientHello pair.
Paragraph (version B):
Upon receipt of a HelloRetryRequest, the client MUST first verify
that the "selected_group" field does not identify a group which was
not in the original ClientHello.  If it was present, then the client
MUST abort the handshake with a fatal "handshake_failure" alert.
Clients SHOULD also abort with "handshake_failure" in response to any
second HelloRetryRequest which was sent in the same connection (i.e.,
where the ClientHello was itself in response to a HelloRetryRequest).
Paragraph (version B):
Otherwise, the client MUST send a ClientHello with a new
ClientKeyShare extension to the server.  The ClientKeyShare MUST
append a new ClientKeyShareOffer which is consistent with the
"selected_group" field to the groups in the original ClientKeyShare.
Paragraph (version B):
Upon re-sending the ClientHello and receiving the server's
ServerHello/ServerKeyShare, the client MUST verify that the selected
CipherSuite and NamedGroup match that supplied in the
HelloRetryRequest.
Paragraph (version A):
An extension type MUST NOT appear in the ServerHello unless the same
extension type appeared in the corresponding ClientHello.  If a
client receives an extension type in ServerHello that it did not
request in the associated ClientHello, it MUST abort the handshake
with an "unsupported_extension" fatal alert.
Paragraph (version B):
An extension type MUST NOT appear in the ServerHello or
HelloRetryRequest unless the same extension type appeared in the
corresponding ClientHello.  If a client receives an extension type in
ServerHello or HelloRetryRequest that it did not request in the
associated ClientHello, it MUST abort the handshake with an
"unsupported_extension" fatal alert.
Paragraph (version A):
Finally, note that extensions can be sent both when starting a new
session and when requesting session resumption.  Indeed, a client
that requests session resumption does not in general know whether the
server will accept this request, and therefore it SHOULD send the
same extensions as it would send if it were not attempting
resumption.
Paragraph (version B):
Finally, note that extensions can be sent both when starting a new
session and when requesting session resumption or 0-RTT mode.
Indeed, a client that requests session resumption does not in general
know whether the server will accept this request, and therefore it
SHOULD send the same extensions as it would send if it were not
attempting resumption.
Paragraph (version A):
In general, the specification of each extension type needs to
describe the effect of the extension both during full handshake and
session resumption.  Most current TLS extensions are relevant only
when a session is initiated: when an older session is resumed, the
server does not process these extensions in ClientHello, and does not
include them in ServerHello.  However, some extensions may specify
different behavior during session resumption.
Paragraph (version A):
When performing session resumption, this extension is not included in
ServerHello, and the server ignores the extension in ClientHello (if
present).
Paragraph (version A):
TLS versions before 1.3 have a strict message ordering and do not
permit additional messages to follow the ClientHello.  The EarlyData
extension allows TLS messages which would otherwise be sent as
separate records to be instead inserted in the ClientHello.  The
extension simply contains the TLS records which would otherwise have
been included in the client's first flight.
Paragraph (version A):
Extra messages for the client's first flight MAY either be
transmitted standalone or sent as EarlyData.  However, when a client
does not know whether TLS 1.3 can be negotiated - e.g., because the
server may support a prior version of TLS or because of network
intermediaries - it SHOULD use the EarlyData extension.  If the
EarlyData extension is used, then clients MUST NOT send any messages
other than the ClientHello in their initial flight.
Paragraph (version A):
Any data included in EarlyData is not integrated into the handshake
hashes directly.  E.g., if the ClientKeyShare is included in
EarlyData, then the handshake hashes consist of ClientHello +
ServerHello, etc.  However, because the ClientKeyShare is in a
ClientHello extension, it is still hashed transitively.  This
procedure guarantees that the Finished message covers these messages
even if they are ultimately ignored by the server (e.g., because it
is sent to a TLS 1.2 server).  TLS 1.3 servers MUST understand
messages sent in EarlyData, and aside from hashing them differently,
MUST treat them as if they had been sent immediately after the
ClientHello.
Paragraph (version A):
Servers MUST NOT send the EarlyData extension.  Negotiating TLS 1.3
serves as acknowledgment that it was processed as described above.
Paragraph (version A):
This message will be sent immediately after the ServerHello
message if the client has provided a ClientKeyShare message which
is compatible with the selected cipher suite and group parameters.
Paragraph (version A):
This message conveys cryptographic information to allow the client
to compute the premaster secret: a Diffie-Hellman public key with
which the client can complete a key exchange (with the result
being the premaster secret) or a public key for some other
algorithm.
Paragraph (version B):
A list of ClientKeyShareOffer values in descending order of client
preference.
Paragraph (version B):
Shortening the handshake because the certificate may be large.
Paragraph (version B):
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 B):
An opaque label for the configuration in question.
Paragraph (version B):
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 B):
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 B):
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 B):
The pre_shared_key extension is used to indicate the identity of the
pre-shared key to be used with a given handshake in association with
a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background).
Paragraph (version B):
An opaque label for the pre-shared key.
Paragraph (version B):
When the client offers a PSK cipher suite, it MUST also supply a
PreSharedKeyExtension to indicate the PSK(s) to be used.  If no such
extension is present, the server MUST NOT negotiate a PSK cipher
suite.  If no suitable identity is present, the server MUST NOT
negotiate a PSK cipher suite.
Paragraph (version B):
If the server selects a PSK cipher suite, it MUST send a
PreSharedKeyExtension with the identity that it selected.  The client
MUST verify that the server has selected one of the identities that
the client supplied.  If any other identity is returned, the client
MUST generate a fatal "handshake_failure" alert.
Paragraph (version B):
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 B):
An optional context value that can be used for anti-replay (see
below).
Paragraph (version B):
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):
If TLS client authentication is being used, then either
"early_handshake" or "early_handshake_and_data" MUST be indicated in
order to send the client authentication data on the first flight.  In
either case, the client Certificate and CertificateVerify (assuming
that the Certificate is non-empty) MUST be sent on the first flight A
server which receives an initial flight with only "early_data" and
which expects certificate-based client authentication MUST not accept
early data.
Paragraph (version B):
Ignore the extension and return no response.  This indicates that
the server has ignored any early data and an ordinary 1-RTT
handshake is required.
Paragraph (version B):
Return an empty extension, indicating that it intends to process
the early data.  It is not possible for the server to accept only
a subset of the early data messages.
Paragraph (version B):
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):
Whether we really want the Finished to not include the server's
data at all.
Paragraph (version B):
As noted in zero-rtt-exchange, TLS does not provide any inter-
connection mechanism for replay protection for data sent by the
client in the first flight.  As a special case, implementations where
the server configuration, is delivered out of band (as has been
proposed for DTLS-SRTP RFC5763), MAY use a unique server
configuration identifier for each connection, thus preventing replay.
Implementations are responsible for ensuring uniqueness of the
identifier in this case.
Paragraph (version B):
This message will be sent immediately after the ServerHello
message if the client has provided a ClientKeyShare extension
which is compatible with the selected cipher suite and group
parameters.
Paragraph (version B):
This message conveys cryptographic information to allow the client
to compute a shared secret secret: a Diffie-Hellman public key
with which the client can complete a key exchange (with the result
being the shared secret) or a public key for some other algorithm.
Paragraph (version A):
The named group for the key share offer.  This identifies the
selected key exchange method from the ClientKeyShare message
(client-key-share), identifying which value from the
ClientKeyShareOffer the server has accepted as is responding to.
Paragraph (version A):
If this message is sent, it MUST be sent immediately after the
server's ServerKeyShare.
Paragraph (version B):
The named group for the key share offer.  This identifies the
selected key exchange method from the ClientKeyShare (client-key-
share), identifying which value from the ClientKeyShareOffer the
server has accepted as is responding to.
Paragraph (version B):
If this message is sent, it MUST be sent immediately after the
server's ServerKeyShare.  This is the first message that is
encrypted under keys derived from ES.
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).  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), 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 A):
The "server_name" and "trusted_ca_keys" extensions RFC6066 are
used to guide certificate selection.
Paragraph (version B):
The "server_name" and "trusted_ca_keys" extensions RFC6066 are
used to guide certificate selection.  As servers MAY require the
presence of the server_name extension, clients SHOULD send this
extension.
Paragraph (version B):
This message is used to provide a server configuration which the
client can use in future to skip handshake negotiation and
(optionally) to allow 0-RTT handshakes.  The ServerConfiguration
message is sent as the last message before the CertificateVerify.
Paragraph (version B):
The configuration identifier to be used with the known
configuration extension known-configuration-extension.
Paragraph (version B):
The group for the long-term DH key that is being established for
this configuration.
Paragraph (version B):
The long-term DH key that is being established for this
configuration.
Paragraph (version B):
Whether the client may send data in its first flight (see early-
data-indication).
Paragraph (version B):
When the ServerConfiguration message is sent, the server MUST also
send a Certificate message and a CertificateVerify message, even if
the "known_configuration" extension was used for this handshake, thus
requiring a signature over the configuration before it can be used by
the client.
Paragraph (version A):
Here handshake_messages_hash is a digest of all handshake messages
sent or received, starting at ClientHello and up to, but not
including, this message, including the type and length fields of
the handshake messages.  This is a digest of the concatenation of
all the Handshake structures (as defined in handshake-protocol)
exchanged thus far.  For the PRF defined in Section 5, the digest
MUST be the Hash used as the basis for the PRF.  Any cipher suite
which defines a different PRF MUST also define the Hash to use in
this computation.  Note that this is the same running hash that is
used in the Finished message server-finished.
Paragraph (version B):
Where session_hash is as described in the-handshake-hash and
includes the messages sent or received, starting at ClientHello
and up to, but not including, this message, including the type and
length fields of the handshake messages.  This is a digest of the
concatenation of all the Handshake structures (as defined in
handshake-protocol) exchanged thus far.  The digest MUST be the
Hash used as the basis for HKDF.
Paragraph (version A):
The Server's Finished message is the final message sent by the
server and indicates that the key exchange and authentication
processes were successful.
Paragraph (version B):
The Server's Finished message is the final message sent by the
server and is essential for providing authentication of the server
side of the handshake and computed keys.
Paragraph (version A):
Recipients of Finished messages MUST verify that the contents are
correct.  Once a side has sent its Finished message and received
and validated the Finished message from its peer, it may begin to
send and receive application data over the connection.  This data
will be protected under keys derived from the hs_master_secret
(see cryptographic-computations).
Paragraph (version A):
Hash denotes a Hash of the handshake messages.  For the PRF
defined in HMAC, the Hash MUST be the Hash used as the basis for
the PRF.  Any cipher suite which defines a different PRF MUST also
define the Hash to use in the Finished computation.
Paragraph (version A):
In previous versions of TLS, the verify_data was always 12 octets
long.  In the current version of TLS, it depends on the cipher
suite.  Any cipher suite which does not explicitly specify
verify_data_length has a verify_data_length equal to 12.  This
includes all existing cipher suites.  Note that this
representation has the same encoding as with previous versions.
Future cipher suites MAY specify other lengths but such length
MUST be at least 12 bytes.
Paragraph (version A):
All of the data from all messages in this handshake (not including
any HelloRequest messages) up to, but not including, this message.
This is only data visible at the handshake layer and does not
include record layer headers.  This is the concatenation of all
the Handshake structures as defined in handshake-protocol,
exchanged thus far.
Paragraph (version A):
The value handshake_messages includes all handshake messages starting
at ClientHello up to, but not including, this Finished message.  This
may be different from handshake_messages in server-certificate-verify
or client-certificate-verify.  Also, the handshake_messages for the
Finished message sent by the client will be different from that for
the Finished message sent by the server, because the one that is sent
second will include the prior one.
Paragraph (version A):
Note: Alerts and any other record types are not handshake messages
and are not included in the hash computations.  Also, HelloRequest
messages are omitted from handshake hashes.
Paragraph (version B):
Recipients of Finished messages MUST verify that the contents are
correct.  Once a side has sent its Finished message and received
and validated the Finished message from its peer, it may begin to
send and receive application data over the connection.  This data
will be protected under keys derived from the ephemeral secret
(see cryptographic-computations).
Paragraph (version B):
HMAC(finished_secret, finished_label + '\0' + handshake_hash)
where HMAC uses the Hash algorithm for the handshake.  See the-
handshake-hash for the definition of handshake_hash.
Paragraph (version B):
In previous versions of TLS, the verify_data was always 12 octets
long.  In the current version of TLS, it is the size of the HMAC
output for the Hash used for the handshake.
Paragraph (version B):
Note: Alerts and any other record types are not handshake messages
and are not included in the hash computations.  Also, HelloRequest
messages and the Finished message are omitted from handshake hashes.
The input to the client and server Finished messages may not be the
same because the server's Finished does not include the client's
Certificate and CertificateVerify message.
Paragraph (version A):
This message conveys the client's certificate chain to the server;
the server will use it when verifying the CertificateVerify
message (when the client authentication is based on signing) or
calculating the premaster secret (for non-ephemeral Diffie-
Hellman).  The certificate MUST be appropriate for the negotiated
cipher suite's key exchange algorithm, and any negotiated
extensions.
Paragraph (version B):
This message conveys the client's certificate chain to the server;
the server will use it when verifying the CertificateVerify
message (when the client authentication is based on signing).  The
certificate MUST be appropriate for the negotiated cipher suite's
key exchange algorithm, and any negotiated extensions.
Paragraph (version B):
After the server has received the client Finished message, it MAY
send a NewSessionTicket message.  This message MUST be sent before
the server sends any application data traffic, and is encrypted under
the application traffic key.  This message creates a pre-shared key
(PSK) binding between the resumption master secret and the ticket
label.  The client MAY use this PSK for future handshakes by
including it in the pre_shared_key extension in its ClientHello (pre-
shared-key-extension) and supplying a suitable PSK cipher suite.
Paragraph (version B):
Indicates the lifetime in seconds as a 32-bit unsigned integer in
network byte order.  A value of zero is reserved to indicate that
the lifetime of the ticket is unspecified.
Paragraph (version B):
The value of the ticket to be used as the PSK identifier.
Paragraph (version B):
The ticket lifetime hint is informative only.  A client SHOULD delete
the ticket and associated state when the time expires.  It MAY delete
the ticket earlier based on local policy.  A server MAY treat a
ticket as valid for a shorter or longer period of time than what is
stated in the ticket_lifetime_hint.
Paragraph (version B):
The ticket itself is an opaque label.  It MAY either be a database
lookup key or a self-encrypted and self-authenticated value.
Section 4 of RFC5077 describes a recommended ticket construction
mechanism.
Paragraph (version A):
In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and
the client and server random values.  The authentication, key
agreement, and record protection algorithms are determined by the
cipher_suite selected by the server and revealed in the ServerHello
message.  The random values are exchanged in the hello messages.  All
that remains is to calculate the master secret.
Paragraph (version A):
The pre_master_secret is used to generate a series of master secret
values, as shown in the following diagram and described below.
Paragraph (version A):
During resumption, the premaster secret is initialized with the
"resumption premaster secret", rather than using the values from the
ClientKeyShare/ServerKeyShare exchange.
Paragraph (version A):
This master secret value is used to generate the record protection
keys used for the handshake, as described in key-calculation.
Paragraph (version A):
Once the hs_master_secret has been computed, the premaster secret
SHOULD be deleted from memory.
Paragraph (version A):
Once the last non-Finished message has been sent, the client and
server then compute the master secret which will be used for the
remainder of the session.  It is also used with TLS Exporters
RFC5705.
Paragraph (version A):
If the server does not request client authentication, the master
secret can be computed at the time that the server sends its
Finished, thus allowing the server to send traffic on its first
flight (See [TODO] for security considerations on this practice.)  If
the server requests client authentication, this secret can be
computed after the client's Certificate and CertificateVerify have
been sent, or, if the client refuses client authentication, after the
client's empty Certificate message has been sent.
Paragraph (version A):
The session_hash value is a running hash of the handshake as defined
in the-session-hash.  Thus, the hs_master_secret is generated using a
different session_hash from the other two secrets.
Paragraph (version A):
All master secrets are always exactly 48 bytes in length.  The length
of the premaster secret will vary depending on key exchange method.
Paragraph (version A):
where "handshake_messages" refers to all handshake messages sent or
received, starting at ClientHello up to the present time, with the
exception of the Finished message, including the type and length
fields of the handshake messages.  This is the concatenation of all
the exchanged Handshake structures.
Paragraph (version A):
For concreteness, at the point where the handshake master secret is
derived, the session hash includes the ClientHello, ClientKeyShare,
ServerHello, and ServerKeyShare, and HelloRetryRequest (if any)
(though see [https://github.com/tlswg/tls13-spec/issues/104]).  At
the point where the master secret is derived, it includes every
handshake message, with the exception of the Finished messages.  Note
that if client authentication is not used, then the session hash is
complete at the point when the server has sent its first flight.
Otherwise, it is only complete when the client has sent its first
flight, as it covers the client's Certificate and CertificateVerify.
Paragraph (version A):
A conventional Diffie-Hellman computation is performed DH.  The
negotiated key (Z) is used as the pre_master_secret, and is converted
into the master_secret, as specified above.  Leading bytes of Z that
contain all zero bits are stripped before it is used as the
pre_master_secret.
Paragraph (version A):
All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) are performed according to [6]
using the ECKAS-DH1 scheme with the identity map as key derivation
function (KDF), so that the premaster secret is the x-coordinate of
the ECDH shared secret elliptic curve point represented as an octet
string.  Note that this octet string (Z in IEEE 1363 terminology) as
output by FE2OSP, the Field Element to Octet String Conversion
Primitive, has constant length for any given field; leading zeros
found in this octet string MUST NOT be truncated.
Paragraph (version B):
In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and
the client and server random values.  The authentication, key
agreement, and record protection algorithms are determined by the
cipher_suite selected by the server and revealed in the ServerHello
message.  The random values are exchanged in the hello messages.  All
that remains is to calculate the key schedule.
Paragraph (version B):
The TLS handshake establishes secret keying material which is then
used to protect traffic.  This keying material is derived from the
two input secret values: Static Secret (SS) and Ephemeral Secret
(ES).
Paragraph (version B):
These shared secret values are used to generate cryptographic keys as
shown below.
Paragraph (version B):
The derivation process is as follows, where L denotes the length of
the underlying hash function for HKDF.
Paragraph (version B):
The traffic keys are computed from xSS, xES, and the master_secret as
described in traffic-key-calculation below.
Paragraph (version B):
The Record Protocol requires an algorithm to generate keys required
by the current connection state (see the-security-parameters) from
the security parameters provided by the handshake protocol.
Paragraph (version B):
A string label that indicates the purpose of keys being generated.
Paragraph (version B):
The current handshake hash.
Paragraph (version B):
The total length in octets of the key block.
Paragraph (version B):
All handshake messages sent or received, starting at ClientHello
up to the present time, with the exception of the Finished
message, including the type and length fields of the handshake
messages.  This is the concatenation of all the exchanged
Handshake structures in plaintext form (even if they were
encrypted on the wire).
Paragraph (version B):
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):
This final value of the handshake hash is referred to as the "session
hash" because it contains all the handshake messages required to
establish the session.  Note that if client authentication is not
used, then the session hash is complete at the point when the server
has sent its first flight.  Otherwise, it is only complete when the
client has sent its first flight, as it covers the client's
Certificate and CertificateVerify.
Paragraph (version B):
A conventional Diffie-Hellman computation is performed.  The
negotiated key (Z) is used as the shared_secret, and is used in the
key schedule as specified above.  Leading bytes of Z that contain all
zero bits are stripped before it is used as the input to HKDF.
Paragraph (version B):
All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) are performed according to [6]
using the ECKAS-DH1 scheme with the identity map as key derivation
function (KDF), so that the shared secret is the x-coordinate of the
ECDH shared secret elliptic curve point represented as an octet
string.  Note that this octet string (Z in IEEE 1363 terminology) as
output by FE2OSP, the Field Element to Octet String Conversion
Primitive, has constant length for any given field; leading zeros
found in this octet string MUST NOT be truncated.