- 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."
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?
- 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
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:
- 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.
- 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.
- 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.