Merged. On Thu, May 19, 2016 at 10:41 AM, Eric Rescorla <e...@rtfm.com> wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/454 > > I have uploaded a PR [technically two PRs, but one builds on the > other, so easier to just read the composition] which resolves two out > of the three significant remaining crypto issues (the remaining one is > the long-running discussion of post-handshake keys). The following > message lays out the changes, which are: > > - Adopt a more linear key schedule > - Add a context identifier for resumption > > > KEY SCHEDULE > We had a lot of comments that the existing key schedule was too hard > to understand and implement and could be simplified under the > assumption that keys were available in a specific order (PSK then DH > ZZ). I've been working together with Karthik, Hugo, Antoine, and > others to produce something cleaner. (Note: I believe they consider > this acceptable, but that doesn't mean they wouldn't have designed > every piece exactly as I have.) > > > The overall key schedule looks like this: > > 0 > | > v > PSK -> HKDF-Extract > | > v > Early Secret --> Derive-Secret(., "early traffic secret", > | ClientHello) > | = early_traffic_secret > v > (EC)DHE -> HKDF-Extract > | > v > Handshake > Secret -----> Derive-Secret(., "handshake traffic secret", > | ClientHello + ServerHello) > | = handshake_traffic_secret > v > 0 -> HKDF-Extract > | > v > Master Secret > | > +---------> Derive-Secret(., "application traffic secret", > | ClientHello...Server > Finished) > | = traffic_secret_0 > | > +---------> Derive-Secret(., "exporter master secret", > | ClientHello...Client Finished) > | = exporter_secret > | > +---------> Derive-Secret(., "resumption master secret", > ClientHello...Client Finished) > = resumption_secret > > Derive-Secret(Secret, Label, Messages) = > HKDF-Expand-Label(Secret, Label, > Hash(Messages) + resumption_context, L)) > > > Derive-Secret is just a wrapper around HKDF-Expand-Label, for reasons > indicated below. If a key is missing you just use 0s. > > 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. All > the working keys (both encryption keys and finished keys) are > generated using HKDF-Expand-Label off of the traffic secrets. > > This design is motivated by the following principles: > > - Separate out adding entropy from adding context. > - Incorporate the transcript once and then derive from there. > - Have a narrow, consistent interface for generating the leaf keys > so they can just start with a base key. > - Derive from keys as soon as practical so that you can destroy them > (thus the final call to Add-Secret, which isolates the > Finished keys from the MS). > > An additional nice point about this design is that it easily > accomodates additional keys. For instance, if we had some post-quantum > key exchange method, we could easily add its key in the final > Add-Secret or add an extra Add-Secret stage before HS. Similarly, if > we had a long-term DH key as in OPTLSv1, it could replace the 0 in the > final Add-Secret. > > One thing I want to call out explicitly is that we are using > HKDF-Expand-Label with the output of HKDF-Expand-Label. This is > cryptographically fine, but means that you need an implementation of > the individual HKDF Expand/Extract primitives. As far as I can tell, > this isn't a hardship for anyone, but please speak up if it is. The > advantage of this is that you remove unnecessary crypto operations. > > > CONTEXT IDENTIFIER > PR: https://github.com/tlswg/tls13-spec/pull/454 > > Hugo and Karthik both independently suggested that it would be nice to > have some identity/context bound into the PSK handshake. The second PR > accomodates that by deriving two values from the RMS: > > resumption_psk = HKDF-Expand-Label(resumption_secret, > "resumption psk", "", L) > > resumption_context = HKDF-Expand-Label(resumption_secret, > "resumption context", "", L) > > The resumption_psk is then used as the PSK for resumption and the > resumption_context is added to the hash of the handshake messages > whenever you use them, currently just by appending to the hash, as in: > > Hash(handshake messages) +resumption_context > > This is used *both* to derive the keys and for the input to > the CertificateVerify/Finished. For convenience, I've > > > Note: the reason for separately deriving RMS and then computing the > context and PSK from RMS is to allow the server to just store RMS in > the ticket. If we used MS the server would need to store MS in the > ticket and then compromise of the ticket key would threaten the > original handshake. > > One nit question, would it be better to hash twice, as in: > > Hash(Hash(handshake messages) + resumption_context) > > I can't see a reason to, but maybe I've missed something. > > Comments welcome. In the interest of not having too many outstanding > changes, I'll probably merge this tomorrow unless someone strongly > objects or we find something really egregious (which is always possible > because there's a lot of text here). > > Best, > -Ekr > > > > > > > > > > > > > > > > > > > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
