TLS Module: The default ecdhCurve, prime256v1 (aka NIST P-256) is not safe.

[mattcollier]

This document states that the default curve for the ecdhCurve parameter is prime256v1.
https://iojs.org/api/tls.html#tls_tls_createserver_options_secureconnectionlistener

Appendix A of this document indicates that prime256v1 is also known as NIST P-256.
http://www.rfc-editor.org/rfc/rfc4492.txt

This site indicates that NIST P-256 is not secure.
http://safecurves.cr.yp.to/

I recommend that a safe alternative should be chosen as the default and unsafe curves should not be made available.

Also posted to nodejs: nodejs/node-v0.x-archive#18205

[Fishrock123]

/cc @indutny

[silverwind]

Good catch, now which curve should we choose?

My OpenSSL has these curves defined: https://gist.github.com/silverwind/9e9090833fce8acffa50

I'm having a hard time matching them to the curve names on http://safecurves.cr.yp.to/. Maybe we need to define a custom curve?

[silverwind]

According to http://security.stackexchange.com/a/78624 client support is pretty limited besides prime256v1 and secp384r1, so that would heavily limit our options.

@mattcollier The linked SE answer raises some doubts about the 'not safe' statement.

[shigeki]

curve25519 is one of the candidates we adopt in the future but it's not been implemented in openssl yet.
We also should care about compatibilities to especially browsers for the default curve. curve25519 is only supported on Safari and Chrome as in http://ianix.com/pub/ed25519-deployment.html while NIST P-256 is included in suiteB and widely deployed at present.
I think we had better to wait and see the ec implementation of openssl and deployment of safer curves in browsers for now.

[bnoordhuis]

I think we should aim for secure by default. The curve is configurable with the ecdhCurve option or globally through the tls.DEFAULT_ECDH_CURVE property; people that want to revert to prime256v1, can. We just need to call it out in the release notes.

I don't know what a good replacement is, though. I don't think http://safecurves.cr.yp.to/ considers any of the existing curves in OpenSSL safe.

[silverwind]

I think this is a non-issue, let me quote above SE answer:

What they mean is not that some curves are inherently unsafe, but that safe implementation of some curves is easier than for others

Use P-256 to minimize trouble. If you feel that your manhood is threatened by using a 256-bit curve where a 384-bit curve is available, then use P-384

If anything, this should probably be brought up to OpenSSL

[indutny]

Yeah, exactly. There are nothing we could do about it right now. Perhaps somewhere later when OpenSSL will implement these safe curves.

[bnoordhuis]

What they mean is not that some curves are inherently unsafe, but that safe implementation of some curves is easier than for others

I don't think that's true. The FIPS mandated curves are suspect because there is reason to believe the NSA may have influenced the decision making process around them.

From https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929:

I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry.

[indutny]

Let's be straight about it. There are three concerns that are mentioned on safecurves.cr.yp.to:

• Rigidity - curve was generated using unexplained constant, this is quite questionable and doesn't raise anything except the suspicion
• Ladder - no ladder scalar multiplication, this may lead to the side-channel attacks. But I believe that OpenSSL mitigates many of them
• Completeness - requires checks for the points (I believe OpenSSL should be fine with this)
• Indistinguishability - prevents attackers recognizing the EC curve point in the data stream. This one doesn't really matter for TLS, because it is easy to recognize the protocol anyway.

So only ladder and rigidity actually apply. This is not that great, but not totally bad either IMHO

[shigeki]

Yes, it is suspicion. How about adding tls.DEFAULT_ECDH_CURVE to doc as 02a51cf ?
That's all we can do now.

[indutny]

Sounds good to me!

[shigeki]

@indutny Thanks. Probably it is following to Ben's comment.
@silverwind How do you think it for closing this issue?

[mattcollier]

I understand there is little to be done at this time because openssl does not currently provide a better alternative. Is there some mechanism in place to keep this issue from being lost and forgotten? Perhaps a "good enough for now" tag?

[shigeki]

I think it is better to put a comment in the source as

diff --git a/lib/tls.js b/lib/tls.js
index 3ae7a8f..44ea058 100644
--- a/lib/tls.js
+++ b/lib/tls.js
@@ -33,6 +33,7 @@ exports.DEFAULT_CIPHERS = [
   '!CAMELLIA'
 ].join(':');

+// reconsider this when more safer curve is available.
 exports.DEFAULT_ECDH_CURVE = 'prime256v1';

 exports.getCiphers = function() {