On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett <[email protected]> wrote:
> On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote: > > I think perhaps you have misunderstood the forward secrecy properties of > the > > current draft. Unlike TLS 1.2 and previous, the current draft has a > separate > > resumption master secret which is independently derived from the master > > secret used for the connection keys in the original connection. This > means > > that if you don't resume the connection, you have forward secrecy for the > > original connection regardless of whether the server stores the session > in > > the session cache or sends the client a ticket. > > We've got lots of keys and secrets now. Could you please clarify the exact > points where these are each to be discarded? If I am understanding it > correctly, the master_secret, prior intermediate secrets, and > finished_secret are to be discarded as soon as the keys, resumption_secret, > and possibly exporter_secret (which currently has no explanation in the > doc) are derived, the handshake is finished, and we're ready for > application traffic? It would help if you provided a table/chart laying out > the timeline of secret & key lifetimes, from derivation to discard. It > should state in the spec explicitly what needs to be kept around for how > long and require things be discarded as soon as viable. > Yes, I can do something along these lines. > I think these various values need to be named more consistently in the doc > to make searching for them easier. For example, "resumption_secret" is used > in the computation part but the words "resumption master secret" are used > when actually using this value. (also noted in issue #191 by Martin > Thomson) I've pushed a small PR to correct this case along with a few > tweaks that I think makes it a bit clearer. > https://github.com/tlswg/tls13-spec/pull/205 > > Also, some other questions about various computations: > > https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-7.1 > https://tlswg.github.io/tls13-spec/#key-schedule > > HKDF(,,,) doesn't seem to be fully defined here, just > HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869. > Could you please clarify this? > Yes. > Why is finished_secret derived from extracted static secret instead of > master_secret? The rationale here is that the Finished message also serves to authenticate the server's ephemeral DH share (when in known_configuration mode) and because the master secret depends on the ephemeral DH keys, this creates an odd authentication logic. Hugo can expand on this some more, perhaps. > Are there two finished_secret in the event that the client sends a > certificate? > No, this shouldn't be necessarily. You just use the first one. I'll try to clarify. > The computation of verify_data could probably be moved up to the same > section so this is all in the same place. Am I correct in reading that it > could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret, > finished_label, handshake_hash, L) without the extra HMAC currently defined > for verify_data) See above. -ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
