1. The NSA says that RSA 2048 should only be used to protect information that need to remain secret for at most a few years. Nobody should be using RSA 2048 to protect information that could get then jailed/hurt/killed 5 or 10 years from now.

2. The main advantage of ECC is that it is generally faster than RSA, especially for security levels that would require RSA keys larger than 2048 bits.

3. It is meaningless at this time to say that ECC is unnecessarily strong compared to RSA. It is possible to match the security of ECC using RSA at every level. But, a linear increase in ECC key size requires the RSA key size to increase exponentially. For example, to match the strength of AES-128 you need a 256-bit ECC key or a 3072-bit RSA key, whereas to match the strength of AES-256 you need a 384-bit ECC key or a 15,360-bit RSA key.

Nobody should store information that could get them jailed/hurt/killed 5 or 10 years from now.

Closely related to the fact it's patent encumbered, there's very little (relatively) work going into the practical side of ECC because the mess of patent surrounding the area.

Almost everybody I know of that is doing real-world cryptography is using or preparing to use ECC. In one or two years I think the typical computer user will be using ECC very frequently. The ECC patents are pretty easy to work around. One very conservative approach is: don't use ECMQV, don't use point compression, only use the Suite B curves, and use Sun's ECC contribution to OpenSSL (as it was created with the benefit of Sun's legal department and probably also reviewed by several other companies), and review the math algorithms used to make sure they were all published before 1994.

Windows Media DRM uses ECC.

These comments regarding ECC are pretty much the exact opposite of reality; ECC is mainstream, and used in plenty of environments because its "ludicrously unnecessary strength" correlates with "smaller, more manageable keys". ECC vs. RSA is a library option setting for pretty much every dev environment in the world.

> but implementations are slow

Well, think about this: One major reason hash functions like sha1 aren't recommended (as opposed to, say, bcrypt) for encryption is because they are optimized for speed and so it's faster to generate lookup tables or to iteratively search for the password. So unless it's slow because the implementation itself is crappy, this might actually be a good thing after all.