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.

Improve this question
6
  • 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
    Commented Nov 7, 2017 at 19:30
  • Related: security.stackexchange.com/questions/37797/…
    – StackzOfZtuff
    Commented Nov 7, 2017 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?
    – StackzOfZtuff
    Commented Nov 7, 2017 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
    Commented Nov 7, 2017 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
    Commented Nov 7, 2017 at 22:49

1 Answer 1

Reset to default
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).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .