Draft: draft-ietf-tls-tls13

Commentary: First cut at a new , more linear key schedule . WIP so possible I missed something serious . comments , please ? Does this seem more straightforward 
 After this change , the keys used to encrypt the handshake traffic are derived from both ES and SS . ( As before , they were derived only from ES ) Does this bring any advantages security - wise ? In the current version , the Finished keys contain the handshake context up to CertificateVeryServer , by being transitively derived from mES and mSS . Now these keys do n't contain handshake context any more . What is the reasoning behind this change ? 
 , svince wrote : In the current version , the Finished keys contain the handshake context up 
 This is pretty good . The simplification is dramatic , which is the number one thing . Well , the number two thing , given that number one is sign - off from the cryptographers ; my limited knowledge of this says that we are using the same basic source of keying material for all the important decisions . Critically , exporters and resumption branch after the client Finished . I think that you can revert the bracketing changes by changing the description of each instead . The fact that there are different keys for different phases is quite important to have in people 's faces , I think . 
 Note that I had some concerns with clarity of the PR : formatting , the description of and a few things . I think that those are pretty important and probably need a little attention before landing this . 
 I 'm currently modeling the handshake using the Tamarin Prover . Now i need to decide how to model key generation . Should I rather already use the new key generation , or use the current one ? How likely will this pull request be merged in the next time ? 
 I expect to have this resolved and in ( though perhaps not identical to this ) by this time next week . , svince wrote : 
 The traffic key is derived by applying HKDF - Extract to the traffic_secret , which in turn is derived by applying HKDF - Extract to the master secret . There is no intermediate HKDF - Extract stage . Is this intended ? Should there be an intermediate Extract stage ? Could the traffic key maybe be derived directly from the master secret , of course together with the correct handshake hash ? 
 Sorry , which line are talking about ? The traffic keys are derived by applying HKDF - Expand - Label to the current traffic secret : key = HKDF - Expand - Label(Secret , phase + " , " + purpose , handshakecontext ,  ) 
 According to [ ] , the traffic key is computed like this : key = HKDF - Expand - Label(Secret , phase + " , " + purpose , handshakecontext , keylength ) , where Secret = trafficsecret According to [ ] , the trafficsecret is computed as follows : trafficsecret0 = HKDF - Expand - Label(mastersecret , " traffic secret " , handshakehash , L ) The note at the end of 7.1 declares " each HKDF - Expand operation is paired with an HKDF - Extract " . But this is not the case for the traffic key , as there is no HKDF - Extract operation performed on trafficsecret . Is this intended ? If so , why ? Would n't it be the same ( security wise ) as directly using the mastersecret to derive the traffic key ? 
 Yes , that 's an oversight . We are currently reworking the key schedule a bit ( see ) and that will have parity between extract and expand . We could derive the traffic keys from MS , but then we would have to either precompute trafficsecret1 ( which is a bit odd ) or keep MS around ( which threatens PFS for resumed connections ) . So we did it this way . 
 Okay thank you for the information . This helped .
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):
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 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):
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):
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):
HKDF's PRK argument is indicated by the arrow coming in from the
left.  For instance, the Early Secret is the PRK 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 HKDF-Expand-Label may take different
Context arguments, even with the same secret.  In a 0-RTT exchange,
HKDF-Expand-Label 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 0s is used.
Paragraph (version A):
The handshake context which is used to generate the keys.