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. 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? Why is finished_secret derived from extracted static secret instead of master_secret? There's a TODO about changes to use of the master_secret here; could you explain this bit please? (I assume this is a work in progress) Are there two finished_secret in the event that the client sends a certificate? 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) Thanks, Dave _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
