On 10/24/13 1:59 PM, Dave Thompson wrote:
(For EC, the specified curve must also be acceptable to client(s) per
ClientHello extension,
which encourages using the callback or choosing a popular curve like P-256.)
So, my understanding is that if the "tmp_ecdh" is set to a curve which
is not supported by the client, then OpenSSL ought to just skip the
elliptic curve cipher suites and pick the next acceptable cipher suite
supported by both the client and server. Is this not the case?
I was puzzled by this message:
http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html
It suggests that if the client offers P-256 and P-384, but the server's
"tmp_ecdh" is set to P-521, then the server will pick an elliptic curve
cipher suite anyway, try to force P-521 on the client, and the handshake
will fail. Hence his assertion "With TLS, no EC is better than crippled
EC." This seems very wrong to me! If the client and server can't agree
on a curve, shouldn't the server just pick a non-elliptic-curve cipher
suite that both it and the client support instead? It seems like
offering EC should never be worse than not offering EC!
The following draft also seems to suggest the same thing, that if client
and server both support an elliptic curve suite, they will pick it, and
then discover that they don't have any curves in common, and give up,
rather than picking a non-EC suite:
http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/
Is this true? And why? It doesn't seem like it should work that way.
--Patrick
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
