What SSL key should I make for IIS: RSA or DH? What bit length is appropriate?

Question

I'm creating an SSL cert for my IIS server and need to know when I should choose the Microsoft RSA SChannel Cryptographic Provider or the Microsoft DH SChannel Cryptographic Provider.

Question 1 Why would someone still need (what I assume is) a legacy certificate of 'DH'?

Given that the default is RSA/1024, I'm assuming that is the most secure choice, and the other one is for legacy reasons.

Question 2 Is there any guide to determine what bit level is appropriate for x device?

I'd be interested in either lab results, a math formula, or your personal experience. I know the different bit levels influence the time needed to secure an SSL session and that is important for low powered devices.

Question 3 How would bit-strength affect these scenarios?

My particular case involves these communication patterns:

1. A website that has powerful clients connecting and disconnecting the session frequently

2. A WCF website that sustains long durations of high IO data transfers

3. A client facing website geared for iPhones, and Desktops

Answer 1

1. RSA and Diffie-Hellman (DH) are just two different algorithms which accomplish a similar goal. For most purposes, there is no overwhelming reason to prefer one algorithm over another (RSA vs Diffie-Hellman). They do have somewhat different performance characteristics. RSA is the standard choice, and it's a fine choice.

2. It's hard to give a one-size-fit-all recommendation on key size, because this is likely to be dependent upon your site's security needs, and because the key size affects performance. My default recommendation would be to use a 1536-bit RSA key. 1024-bit RSA keys should be an absolute bare minimum; however, 1024-bit RSA keys are on the edge of what might become crackable in the near term and are generally not recommended for modern use, so if at all possible, I would recommend 1536- or 2048-bit RSA keys.

   Note that many CAs have recently started deprecating 1024-bit end-entity certificates, as of December 31, 2010: they may issue you a cert for a 1024-bit RSA key, for legacy purposes, if you ask, but they are encouraging people to transition to 2048-bit RSA. Some CAs are requiring 2048-bit keys, no exceptions. Personally, I think 2048-bit RSA is overkill for most purposes and 1536-bit RSA is probably fine, but 2048-bit RSA is accumulating some inertia.

3. The larger the key, the slower initial connection establishment will be. The most likely impact is on your server's load, since the server has to do a few public-key operations for each new device that connects to it (within a 24-hour period or so). The public-key cryptography only incurs a one-time cost, which is paid once when a connection is created (and not paid again for any new connection within about 24 hours or so); the amount of data transferred over the connection is not relevant.

So, my default suggestion would be: select a 1536-bit RSA key, then test on a typical-low end client (e.g., an iPhone) to make sure performance is OK, then test whether your server can handle the number of connections per day associated with that key size. If you have performance problems on the server, consider a crypto accelerator to speed up your server's performance. If you still have serious performance issues, you could consider dropping down to 1024-bit RSA. If you have a security-critical site, like a banking site, use 2048-bit RSA.

Answer 2

1. DH and RSA are different public key algorithms, but there is no appreciable difference in security given equal public key sizes. DH certificates are fairly uncommon, and you don't need to worry about them.

2. The time needed to perform an RSA operation increases approximately as the cube of the modulus size, i.e. a 2048-bit key is about 8 times slower than a 1024-bit key. This mostly affects the server's performance in SSL, because RSA public operations (decrypt, sign) are much faster than private operations (encrypt, verify) and the client only needs to perform a public RSA encryption using the server's public key in most ciphersuites.

3. In your first case, performance would be strongly affected by the use of SSL session resumption. If a client reconnects to the same server using SSL, it has the option of "resuming" a previous session, which allows it to skip the expensive RSA key exchange. In the second case, long-duration transfers are not affected at all by the server's key size, since application data in SSL is encrypted with a symmetric cipher, not the server's RSA key. For the third case, see (2) above.

Answer 3

1. Because many clients don't support better technology.
2. Yes there is. By now RSA/2048 is considered default secure bit-length. There are conversion tables for bit-rate security for different PKC algorithms, but those are not really sepcific cause every new research in the field changes those. There are approximate coefficients.
3. The bit-length affects time of key generation exponentially, Key generation and SSL establishment is only done at the beginning of every secure connection and data is not encrypted with that, So IO transfers don't affect it. Frequent connections might put extra load on server, thats why loaded sites don't offer SSL for default. Check which bit-length/algorithms iPhone supports. Desktops have no problem.