Update signed_params to included hello.random data

[colmmacc]

This change clarifies that the signature over ServerDHParams data is a
signature over the hash of the client + server hello random random data and the
ServerDHParams data.

I believe this small regression was introduced in TLS1.2 with the result
that the TLS1.2 RFC (and current TLS1.3 draft) does not contain sufficient detail
to implement TLS + DHE.

All TLS1.2 clients and servers that I have tested do include the hello random
data (and omitting it would leave implementations open to replay attacks).

[ekr]

Thanks for the PR.

Note that the formal PDU definitions here appear to be correct, so there should
be enough information to implement things correctly:

          case dhe_rsa:
              ServerDHParams params;
              digitally-signed struct {
                  opaque client_random[32];
                  opaque server_random[32];
                  ServerDHParams params;
              } signed_params;

I agree it wouldn't hurt to have the explanatory text be clearer. However, in TLS 1.2 we stopped explicitly saying that things were hashed before signing (because we are treating signing as a primitive), so we probably don't want to say "hash". Maybe just say a signature over the random values
and the params?

[colmmacc]

Ah, this explains my confusion. After reading section 7.4.1.4.1, I formed the opposite impression about signing; that hashing and signing are explicitly different primitive operations and may be composed in a variety of ways.

But I see how that "digitally-signed" seems to be a reserved term that implies both operations.

[ekr]

I'm not trying to discourage you here. If you were confused, others will probably be as well, so if you have some text that you think would clear this up, it would be welcome.

[colmmacc]

Thanks! I've updated the PR with an even simpler diff that I think would have made me less confused when I got to it.