Random numbers used in TLS

Question

I found in the RFC about TLS v1.2 that master_secret is computed this way:

master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random)

while, subsequently, the needed key blocks composing the key material are generated through

  key_block = PRF(SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.server_random +
                  SecurityParameters.client_random);

And here it is my question: is there any difference between SecurityParameters.server_random and ServerHello.random or between the corresponding client's random numbers? And if yes, what is this difference?

---

My opinion: I think SecurityParameters.master_secret is the one computed with the first PRF shown above: so - supposing this "asymmetry" of notation - maybe, also the random numbers in the second PRF are the same used in the first? But, if so, why this different notation?

Answer 1

The master-to-working key derivation is defined as part of the Record Protocol in section 6, and therefore uses only the 'parameters' passed through a theoretical API from the Handshake Protocol in section 7.3 and 7.4 (and 8) which can directly process the handshake messages including both Hello's and the KeyExchange(s) and/or Certificate(s) contents. I suspect this thinking may have come at least in part from IPSec where the data-level 'bearer' processing is largely isolated from the setup/management processing. In practice no SSL/TLS implementation I have looked at enforces this separation; there are normally code blocks (methods etc) for the two protocol levels that are separately usable (and need to be) but share session/connection/crypto state.

Also, it's not clear at all from the notation, but the premaster-to-master happens only when a full handshake (key exchange) is done, while the master-to-working is repeated if and each time a session is resumed using an abbreviated handshake, using the new nonces from the new abbreviated handshake not the ones from the original full handshake; see F.1.4.