Change:
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 <del> send and receive application data over the connection.  This data will be protected under keys derived from the ephemeral secret (see cryptographic-computations). </del> <ins> send and receive application data over the connection. </ins> The key used to compute the finished message is computed from the Base key defined in authentication-messages using HKDF (see key-

Discussion:
First cut at a new, more linear key schedule. WIP so possible I missed something serious. NAME NAME 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 don't contain handshake context any more. What is the reasoning behind this change?
, svince EMAIL 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 EMAIL 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: URL key = HKDF-Expand-Label(Secret, phase + ", " + purpose, handshakecontext, keylength)
According to [URL], the traffic key is computed like this: key = HKDF-Expand-Label(Secret, phase + ", " + purpose, handshakecontext, keylength), where Secret = trafficsecret According to [URL], 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? Wouldn'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 URL) 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.