1

According to RFC5246 A.5 there are cipher suites TLS_DH_RSA_* and TLS_DH_DSS_*.

How / where does the signature algorithm RSA resp. DSA from the cipher suite come into play when using (non-ephermal) Diffie-Hellman key exchange ?

To my understanding, when using (non-ephermal) DH, key exchange between client and server during the TLS handshake works as follows (suppose there is no client certificate):

  1. Server sends its certificate in ServerCertificate message to the client. The certificate includes DH-parameters p, g and the server's public key constituent g^x mod p (RFC3279, 2.3.3, RFC 5246, 8.1.2).
  2. After verifying the certificate, the client chooses private y, computes g^y mod p and sends public key constituent g^y mod p in the ClientKeyExchange message to the server.
  3. The common private key g^(xy) mod p is known to client and server.

As far as I can see, there is no need for a signature here (up to the certificate's own signature, of course), since public visible g^y mod p is of no help for an attacker due to hardness of computing a discrete logarithm.

Added: No duplicate because the linked question in the comments asks for forward security while this question asks about the notation of the cipher suite.

user120513
  • 145
  • 5
  • Just to add: I know that in practice on uses ephermal Diffie-Hellmann because of PFS. However, I want to understand if cipher suites like TLS_DH_RSA_WITH_* makes sense or should be rather TLS_DH_WITH_* (i.e. RSA, DSS omitted). – user120513 Nov 07 '17 at 19:30
  • Related: https://security.stackexchange.com/questions/37797/how-does-non-ephemeral-diffie-hellman-key-exchange-become-compromised-in-ssl-whe – StackzOfZtuff Nov 07 '17 at 21:42
  • 2
    Possible duplicate of [How does non-ephemeral Diffie-Hellman key exchange become compromised in SSL when the RSA private key is leaked?](https://security.stackexchange.com/questions/37797/how-does-non-ephemeral-diffie-hellman-key-exchange-become-compromised-in-ssl-whe) – StackzOfZtuff Nov 07 '17 at 21:52
  • @StackzOfZtuff: Thanks for the link. (1) The don't think it's a duplicate of the linked question because the context of the other question is in essence forward security while my question is more about the notation of the DH-cipher suites. (2) But the accepted answer in the linked question also answers my question: It links RFC2246 where it is specified that, e.g., DH_RSA means a DH certificate that is signed by RSA. – user120513 Nov 07 '17 at 22:46
  • TLSv1.2 changes this; see the text on page 49 just after the itemized list in section 7.4.2 of rfc5246. Also it's spelled 'ephemeral'. And by convention in DH x is the private key for _either_ party and y = g^x mod p is the corresponding publickey for that party. – dave_thompson_085 Nov 07 '17 at 22:49
  • @dave_thompson_085: Thank you very much. That clears things altogether: "The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical" (RFC5246, 7.4.2). So, actually, DSS and RSA doesn't have a meaning in the (EC)DH-cipher suites. – user120513 Nov 07 '17 at 23:29

1 Answers1

1

As noted by @dave_thompson_085 in his comment above, the names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical (see RFC5246, 7.4.2). Actually, the signature algorithms RSA, DSS in the names of these cipher suites have no meaning.

In TLS 1.1, however, as indicated by @StackzOfZtuff , there had been the convention that in a DH_RSA cipher suite a server certificate has to used that is signed by RSA (and similar for the other suites) (see RFC2246, 7.4.2).

user120513
  • 145
  • 5