Here's some additional useful summary writing on ECC curve selection, known weaknesses (both theoretical, and implementation-based), and best practices for effective deployment of ECC in production systems.
tl;dr is, in a very real sense, that naive use of the NIST curves is a route to security failure - a known route to known security failure, not merely a "gee, this isn't ideal" worry about future problems. And, unfortunately, the vast majority of current ECC implementations are defaulting to the default NIST curves and parameters (according to all the data I've seen, although I've yet to see a formal quantitative in-the-wild research project documenting this).
We're often asked why we're not using ECC more broadly in the cryptocloud framework, and the answer is not what people generally expect. No, we're not convinced that "ECC is broken" or "the NSA has backdoored ECC" - those are both silly statements, and not our position in the least. Rather, we know that deploying ECC correctly requires proper curve selection, careful implementation/testing, and peer-review by one of only a small handful of researchers worldwide (in the civilian world, at least) who are genuinely qualified to validate such metrics.
Fortunately, a good number of these researchers - such as Bernstein & Lange, authors of this specific paper - are incredibly generous in sharing their expertise and experience when it comes to such matters. It is to these good folks who we'll turn when we've deployment frameworks to review, prior to beta testing.
All the tools exist to do this right - especially the NaCl libraries, which are improving at a steady clip - but they are not point-and-click, one-step-install at this point in time. At all. Those who rush these ECC deployments, and do so naively (or recklessly) are doing a tremendous disservice to people who are relying on their deployments to retain in-the-wild security. Only a handful of companies are well-staffed enough, internally, to really do ECC right in production-class systems with high confidence their code is solid (Google being an example, with people of Adam Langley's calibre available on-staff to vet such things); the rest of us must solicit genuine expertise from those genuine experts qualified to ensure we're doing it right. Until we're ready to do so, and have done so, deploying production ECC is reckless bordering on wilfully irresponsible.
We're actively working on ECDHE via TLS 1.2 based on the curve3617 family... but we're not moving away from good, 'ole-fashioned DHE (discrete log based PFS key exchange framework, in other words) until we've got ECDHE ready to deploy correctly.
Anyway, here's the underlying paper - worth a read, and not too technical for an interested layperson to digest: