TLS Handshake with DH

Question

I try to understand the TLS Handshake with DH. I googled the concepts and I think I understood the basics. But there are somethings I'm still struggling with. I also read the following two posts Why does the SSL/TLS handshake have a client random? and Why does the SSL/TLS handshake have a client and server random?

I don't understand how client random, server random, pre-master-secret and master-secret relates to the DH parameters.

Is the Client-Public-DH-Value A (A = g^a mod p) the same as the pre-master-secret? and the master-secret the same as the DH secret/Session Key s (s = A^a mod p)?

There are a lot of images e.gl Wikipedia but I don't see the relation between these steps.

Answer 1

Meta: although both are reasonable, I'd actually consider this Q a better fit for security than crypto. Be that as it may ....

In https://security.stackexchange.com/questions/81597/in-psk-tls-how-is-the-key-used-for-encryption-derived (suggested by RoraZ) the steps from premaster to master to working are applicable, but the premaster step (even for DH_PSK) differs from normal DH keyexchanges, plus TLS1.0 is out of date. What is the purpose of pre master secret in SSL/TLS? and What is the purpose of four different secrets shared by client and server in SSL/TLS? similarly focus on the later steps although the former does mention (EC)DH.

So to lay it out:

• the publickey and privatekey values for the two peers are just keys. TLS specs use the notation where X is the privatekey and Y = G^X mod P the publickey, plus an identifier of the party owning the key: dh_Ys is the server publickey and dh_Yc is the client publickey.

  Although TLS isn't careful about it, there is actually a distinction between on the one hand parameters P,G which must be shared between TLS peers and can be shared on a larger scale (such as an organization or community), and on the other hand key(pair)s X,Y which should be unique to one peer and not shared and for ephemeral DH (the preferred kind) should further be unique to one session and not stored.

  In TLS to date (although draft 1.3 proposes to change this) the server selects the group (parameters) and for ephemeral generates the server keypair in that group; the client generates its keypair in the same group for ephemeral.

• the DH agreement value is used as the premaster secret; see RFC5246 sec 8.1.2. With the TLS notation this is Ys^Xc (computed at client) or Yc^Xs (computed at server). This step is (very) different for other keyexchange methods.

• the premaster secret plus the two nonces (client_random and server_random) are used to derive the master secret per 8.1 and then the master secret and the nonces are used to derive the working keys per 6.3. In case of renegotiation, the second derivation (from master secret to working keys) is repeated using the new nonces from the second handshake, see F.1.4. These steps are the same for all keyexchange methods.

  Both key-derivation steps use what is now called the 'pseudo-random function' PRF. Unlike the other steps, this varies between protocol versions: SSL3 used nested MD5 and SHA1 (and didn't label it PRF), TLS1.0 and 1.1 use doubled both HMAC-MD5 and HMAC-SHA1, and TLS1.2 uses doubled HMAC of a hash that can be selected for each ciphersuite but so far is always SHA-256 or SHA-384.