Draft: draft-ietf-tls-tls13

Commentary: WIP PR for adding a " context " string when we resume 
 Server Name Indication could be encrypted to protect it from being inspected by passive attackers . There are some virtual - hosting type situations where hiding this information is considered desirable . If we can encrypt SNI , then it is probably trivial to encrypt other extensions . However , this complicates the handshake . A lot . It also complicates virtual - hosting scenarios . Rich summarizes the issues pretty well here : 
 Is this already ruled - out ? How could the SNI be encrypted without an addition RTT ? One could hash the SNI in the Client Hello which would at least help if the served host name is not publicly known ( e.g. using a self - signed certificate ) . 
 It seems likely that there will eventually be an ( optional ? ) extension that permits an encrypted " real " SNI , with some fake public SNI . But maybe that is not what you are asking . 
 why was this closed ? 
 Because we are not going to do anything about it in the base specification .
Paragraph (version A):
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 secret (with the exception of pre-shared key
only modes).
Paragraph (version A):
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 A):
Master Secret (MS): A secret derived from both the static and the
ephemeral secret.
Paragraph (version A):
In a pure (EC)DHE cipher suite, ES and SS will both be the (EC)DHE
shared secret.
Paragraph (version A):
In a pure PSK cipher suite, ES and SS will both be the PSK.
Paragraph (version A):
In an (EC)DHE-PSK cipher suite, ES will be the (EC)DHE shared
secret and SS will be the PSK.
Paragraph (version A):
A Handshake Context based on the handshake hash (see the-
handshake-hash).
Paragraph (version A):
A signature over the hash of Handshake Context + Certificate.
Paragraph (version A):
A MAC over the hash of Handshake Context + Certificate +
CertificateVerify using a MAC key derived from the base key.
Paragraph (version B):
A MAC over the value Hash(Handshake Context + Certificate +
CertificateVerify) + Hash(resumption_context) using a MAC key
derived from the base key.
Paragraph (version B):
If this is a resumed handshake (i.e., using resumption PSK), then the
resumption_context value is the resumption_context corresponding to
the PSK.  Otherwise, it is a string of zeros as long as the hash
length.
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 ephemeral secret
(see cryptographic-computations).
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.
Paragraph (version A):
At any time after the server has received the client Finished
message, it MAY send a NewSessionTicket message.  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.  Servers may send multiple tickets on a single
connection, for instance after post-handshake authentication.
Paragraph (version B):
The client MAY use this PSK for future handshakes by including the
ticket value in the "pre_shared_key" extension in its ClientHello
(pre-shared-key-extension) and supplying a suitable PSK cipher suite.
Servers may send multiple tickets on a single connection, for
instance after post-handshake authentication.
Paragraph (version A):
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 A):
These shared secret values are used to generate cryptographic keys as
shown below.
Paragraph (version A):
The derivation process is as follows, where L denotes the length of
the underlying hash function for HKDF RFC5869.  SS and ES denote the
sources from the table above.
Paragraph (version A):
The traffic keys are computed from xSS, xES, and the traffic_secret
as described in traffic-key-calculation below.  The traffic_secret
may be updated throughout the connection as described in updating-
traffic-keys.
Paragraph (version A):
Note: Although the steps above are phrased as individual HKDF-Extract
and HKDF-Expand operations, because each HKDF-Expand operation is
paired with an HKDF-Extract, it is possible to implement this key
schedule with a black-box HKDF API, albeit at some loss of efficiency
as some HKDF-Extract operations will be repeated.
Paragraph (version B):
HKDF-Extract is drawn as taking the Salt argument from the top and
the IKM argument from the left.
Paragraph (version B):
Derive-Secret's Secret argument is indicated by the arrow coming
in from the left.  For instance, the Early Secret is the Secret
for generating the early_traffic-secret.
Paragraph (version B):
The general pattern here is that the secrets shown down the left side
of the diagram are just raw entropy without context, whereas the
secrets down the right side include handshake context and therefore
can be used to derive working keys without additional context.  Note
that the different calls to Derive-Secret may take different Messages
arguments, even with the same secret.  In a 0-RTT exchange, Derive-
Secret is called with four distinct transcripts; in a 1-RTT only
exchange with three distinct transcripts.
Paragraph (version B):
If a given secret is not available, then the 0-value consisting of a
string of L zeroes is used.
Paragraph (version A):
The handshake context which is used to generate the keys.
Paragraph (version A):
Note: the inner HKDF-Extract is strictly unnecessary, but it
maintains the invariant that HKDF Extract and Expand calls are
paired.