The arguments for ECC are (a) it is much more efficient than RSA so you can use stronger keys at less cost, (b) ECDHE is so much faster than DHE (over the integers mod Z) that ECDHE becomes practical in situations where DHE wasn't, (c) it is in NSA Suite B, (d) the major crypto libraries already implement it.
The arguments for AES-GCM: (a) AES-GCM and AES-CCM are the only standardized CTR modes in TLS, (b) you can implement AES-GCM efficiently in constant time (see http://www.cryptojedi.org/papers/aesbs-20090616.pdf), (c) it is the NSA suite B cipher mode, (d) the alternate mode for AES in TLS (AES-CBC-SHA) requires a new initialization vector for every TLS record, which means that you need to get 128 bits of from your PRNG for every 16KB of data transfered, whereas AES-GCM mode only requires 128 bits total per connection. A strong argument against GCM mode is that OpenSSL, NSS, and the Windows CryptoAPI (prior to Windows 7/2008R2) do not implement it yet.
Do you have a link to something that shows that AES-CTR-HMAC-SHA-256 is really faster than AES-GCM? That is something I've always wondered about.
Since you'll be at a BSD conference, I bet you won't get too many people questioning your suggestion to use OpenSSL. But, in the Linux world it seems there's a big push by Red Hat, SuSe, and other enterprise Linux vendors to replace OpenSSL with NSS in every application they support, because of NSS's huge advantages over OpenSSL w.r.t. FIPS-140 validation.
There are some circumstances (e.g., mobile phones) where the efficiency of ECC is useful. But in the vast majority of applications, RSA is not going to be your bottleneck and nobody is going to be attacking the cryptographic primitive itself.
The only difference between AES-GCM and AES-CTR-HMAC-SHA256 is the MAC -- for encryption, AES-GCM just uses AES-CTR. So the question comes down to which MAC is better -- HMAC-SHA256 or evaluate-a-polynomial-over-a-finite-field-then-AES-encrypt. The latter is possible to do in constant time, but takes some work; the former is almost impossible to do not in constant time. As for performance, I haven't done any tests, but just given the bit-complexity of finite field multiplication, I'm sure HMAC-SHA256 is much faster.
For the record, I would never recommend AES-CBC-SHA. That's an absolutely horrible construction which nobody should ever use.
Well, mobile phones are a huge market for this stuff right now. I've found that regular DHE adds latency perceivable by the end user in my mobile apps, because they have to wait for the (fast but heavily-loaded) server to calculate the modular exponentiation, and then they have to wait for their slow phone's processor to calculate the modular exponentiation.
When I said AES-CBC-SHA, I meant AES-CBC-HMAC-SHA. The TLS ciphersuites are named without explicitly saying "HMAC"; e.g. TLS_RSA_WITH_AES_128_CBC_SHA is RSA key exchange with AES-128 in CBC mode as the bulk cipher, authenticated with HMAC-SHA1.
The practical problem that people will have with your advice is that they will want to implement it using TLS (despite your recommendation not to use SSL), and TLS doesn't have any standard AES-CTR-[HMAC-]SHA256 cipher suites; there's only standards for AES-CBC-[HMAC-]SHA, AES-GCM, and AES-CCM.
Yes, I assumed you meant AES-CBC-HMAC-SHA. But CBC mode is horrible, and nobody should use SHA any more.
And I agree that out of AES-CBC-SHA, AES-GCM, and AES-CCM, the best choice is AES-GCM. But my advice was primarily directed towards people not using TLS.
The arguments for AES-GCM: (a) AES-GCM and AES-CCM are the only standardized CTR modes in TLS, (b) you can implement AES-GCM efficiently in constant time (see http://www.cryptojedi.org/papers/aesbs-20090616.pdf), (c) it is the NSA suite B cipher mode, (d) the alternate mode for AES in TLS (AES-CBC-SHA) requires a new initialization vector for every TLS record, which means that you need to get 128 bits of from your PRNG for every 16KB of data transfered, whereas AES-GCM mode only requires 128 bits total per connection. A strong argument against GCM mode is that OpenSSL, NSS, and the Windows CryptoAPI (prior to Windows 7/2008R2) do not implement it yet.
Do you have a link to something that shows that AES-CTR-HMAC-SHA-256 is really faster than AES-GCM? That is something I've always wondered about.
Since you'll be at a BSD conference, I bet you won't get too many people questioning your suggestion to use OpenSSL. But, in the Linux world it seems there's a big push by Red Hat, SuSe, and other enterprise Linux vendors to replace OpenSSL with NSS in every application they support, because of NSS's huge advantages over OpenSSL w.r.t. FIPS-140 validation.