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

This page has some interesting benchmarks that show the effect of key size on performance: https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/

Answer 4

1. I do not believe the Diffie-Hellman (DH) choice is legacy, which means obsolete and superseded, it just is not used very often. In my opinion, that's because it's not the first one in the dropdown when choosing your Cryptographic Service Provider when making a certificate request. If someone is actually doing their homework when they make their choice, however, they still would probably not choose DH. According to Microsoft, the reason to choose one or the other is that you would:

"Select Microsoft DH SChannel Cryptographic Provider when you must exchange a secret key over a network that is not secure and you have had no prior communication with the other party."

Reference: https://technet.microsoft.com/en-us/library/cc725579%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

To me, this would also lead most to just use RSA, since usually you are not exchanging keys across an unsecure network - you are passing your key to your Certificate Authority using your intranet (if self-signing) or perhaps encrypted e-mail or across SSL when communicating to a 3rd-party provider certificate issuing site. Why get something more luxurious/non-standard when you don't need it?

2. and 3. My personal experience is when you have a longer bit length, you need more processing time/speed/power to decrypt your communication. This means more load on the server, more potential for the memory buffer getting clogged while processing, spiking the CPU/RAM, etc. You have to balance this with the need for secure communication. Generally, you want to get the highest bit length your hardware can handle, which will usually be a function of the security needed for your organization - i.e. generally banks, financial institutions, government agencies, etc. will shell out more money for the kind of hardware needed to support the higher bit lengths (2048+) because of the sensitivity of the information. Higher than 2048, however, can give poor performance on your standard, off-the-shelf server hardware, i.e. those servers that are built at the minimum operating specs the Operating System builder recommends to run their server OS. My experience is anything less than dual-core processors, 4 GB RAM, will give you issues for even just starting the site with bit lengths > 2048.

And, of course, you also have to balance your bit-length and specs against your expected user base and concurrent connections, which has a formula of:

Concurrent Connections = Number of Sessions Per Hour x Average Session Duration (in seconds) / 3,600

Reference: http://support.loadimpact.com/knowledgebase/articles/265461-calculating-the-number-of-concurrent-users-to-test

I don't know the direct correlation between this number and CPU GHz you might want - or if this exists as a standard ratio you want to adhere to, since it will likely vary based on CPU architecture, cache/buffer size, FSB, manufacturer (AMD vs. Intel), etc. But I think it's obvious that the higher the number, the more RAM you'll need to prevent the CPU from getting bogged down, and faster CPU speed you'll need to keep up with the demand. Obviously the amount of data being served up contributes to this factor - the time this takes to be served is called latency, and the less latency you have (faster internal network) and more data being transmitted, it can be too fast and too much for your CPU to process over SSL if it is not beefy enough to work (read, encrypt) under the demand.

For your individual questions under Question 3:

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

This has implications on the encryption ramp-up on the server-side, but the disconnect cost is really nothing, as far as SSL goes - it's like a light switch being shut-off. And this goes back more to the number of connections that start connecting simultaneously. You'd monitor your CPU and RAM usage during the connection openings and if it's spiking those in your Process Monitor, you know you might need either a lesser bit-length or more resources, or both.

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

This depends - are the transfers a single request with a lot of data behind them, or many transfers with small packets? The former is usually easier on the CPU/RAM than the latter. You're also talking more about bandwidth than the encryption processing, since that will more than likely be your bottleneck more than the processing power taken by SSL encryption/decryption.

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

If we're talking phones, we're talking 4G connection, which is probably going to be your bottleneck more than its processing power to decrypt the bits, as long as we're talking 2048 or lower. A site geared for a phone is generally going to have fewer graphics/data involved if the programmer is worth their salt, so there should be less to encrypt and transfer. A site for a desktop is a different animal since the desktop will usually be hard-wired to a network, and will (generally) have more processing power than a phone. For the server, it's still about CPU/RAM vs. bit length to process/serve the SSL encrypted bits, and it's going to be different if you're talking about a mobile-geared site vs. a standard site. A mobile-geared site should (theoretically) have less bits to encrypt, therefore take less processing power, allowing a higher bit length. The opposite would apply for a full, desktop-geared site.

Answer 5

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.