Is there any benefit in including the P-384 curve in the Modern suite?

[zofrex]

I am using the recommended settings of the modern suite, and testing via SSLLabs there isn't a single client that can connect and uses prime256v1 – everything either isn't connecting at all or uses secp384r1 or secp521r1.

Is there any client of note that supports TLS 1.2 and the ciphers in the Modern suite but doesn't support secp384r1?

[ekr]

Is there some reason to favor P-384 over P-256?

[zofrex]

I assume bigger numbers are better? I have no more robust reasoning than that 😅

[nshopik]

Its same reason most browsers prefer cipher suites with AES-128 first and then try AES-256. Performance/battery usage, balanced approach

[cmoore1776]

Is there some reason to favor P-384 over P-256?

I suggest you look over https://safecurves.cr.yp.to/ In short, they are both potentially unsafe for exactly the same reasons:

1. Both have coefficients generated by hashing an unexplained seed that could have been chosen by NSA specifically for a weakness that only they know about

2. Neither support a Montgomery ladder, meaning it can take different amounts of time to perform point multiplication on different parts of the curve, thus making it more vulnerable to side channel attacks

3. Neither is "complete", a term for indicating that standardized ECC formulas will work for every rational point on the curve, without exception. If a curve is not complete, the standard formulas don't work, and so whatever implements them needs to properly use error checking to make sure the point addition is accurate. This opens the curve up more opportunities for manipulation by an attacker if error checking is poorly implemented.

4. Neither have Elligator maps, which are tools used to represent points on the curve in such a way that they are essentially indistinguishable from random strings. This makes the fact that you are using these curves more visible to an attacker who may wish to censor you, or collect and analyze enough data until a weakness is found.

[ekr]

@shamelesscookie: yes, i'm aware of these points but they're not really relevant to the question at hand here, which is whether we should support P-384 for clients we're already going to use NIST curves for (probably because they don't support any non-NIST EC at all).

In addition, point 4 is not applicable to TLS, because the TLS handshake negotiates the curve being used in the clear.

[tomato42]

to answer the question in the subject: in the current openssl (1.1.1) P-256 (aka prime256v1, aka secp256r1) is over an order of magnitude faster than P-384 for Diffie-Hellman: 18535 op/s vs 1333 op/s (on a 4GHz frequency locked i7 4790K); P-521 is actually faster than P-384 now, it manages 3008 op/s; but P-521 support is not as widespread as P-384

at the same time, there are no attacks that have significantly weakened P-256, it still is considered to be at the full 128 bit level of security (2^128 work factor) the same one as AES-128 and SHA-256 are

then we have the problem of long-term secrets, even if CAs have root certificates with P-384 curve, intermediate certificates are P-256, so using anything bigger doesn't really increase security

so to reiterate ekr's question: are there any reasons to remove P-256 and replace it with P-384?

[gene1wood]

Given the rationale above it sounds like there's not an appetite for this change

[zofrex]

Thank you everyone who contributed to the discussion, there's lots of really good info here!

Given the points made above I think the original question is maybe not the most pertinent now. Given the points that P-256 is secure enough, and that P-384 is an order of magnitude slower, I think the relevant question might now be:

Is there any benefit in including the P-384 curve in the Modern suite?

The discussion here really answered well the question of whether P-384 should be used over P-256 in theory, but I want to draw attention to the fact that in practice, browsers are picking 384 when both are available (at least according to SSL Labs' simulation of handshakes). If P-256 is good enough, and significantly faster than P-384, would it make sense to remove P-384 from the list so that browsers pick P-256 instead?

[tomato42]

because P-384 is part of the (deprecated, but enshrined in code) Suite B so it is the most widely deployed curve other than P-256. If it is widely deployed and enabled, in case of ECC breakthrough that significantly weakens those curves, but does not break them completely, we have a way to switch to the more secure curve right away - it won't require configuration changes on both servers and clients to align before we'll be able to switch to it.

[zofrex]

That makes sense to me. Thanks!

On the very original point:

testing via SSLLabs there isn't a single client that can connect and uses prime256v1 – everything either isn't connecting at all or uses secp384r1 or secp521r1

This was due to having the protocols in the wrong order – secp521r1:secp384r1:prime256v1 instead of prime256v1:secp384r1:secp521r1. I'm now seeing usage of P-256 even with P-384 permitted. That seems like it achieves both goals of being fast but allowing client-only upgrades to P-384 later if needed.

I think that means this is settled after all? Thanks again everyone who contributed.