> From: owner-openssl-users On Behalf Of Patrick Pelletier > Sent: Friday, October 25, 2013 02:53
> 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? > That's what OpenSSL does -- if there is another mutually acceptable suite. In particular if the server has an RSA key/cert and the client offers both ECDHE-RSA but not the server's curve and akRSA, OpenSSL will choose akRSA and work, but without forward secrecy. If the server has ECDSA key/cert (only) and the client offers ECDHE-ECDSA and ECDHE-RSA but not the server's curve and akRSA, none can work and handshake fails. (Similarly for static-ECDH, and AECDH but in most situations anonymous suites aren't acceptable at all.) > 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 He doesn't say, and I don't know, if the cited servers are OpenSSL. And if they are, what suites they enable. Someone who thinks P-521 is needed today might also try to force forward secrecy. But if OpenSSL server has a choice of EC with unagreed curve and something else, it will go with the something else, which is still better than nothing. (Unless the something else is something badly stupid like export RSA-512 DES-40 MD5.) > 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! > I agree. I think he meant that if the server is mishandling EC nego and thus causing fallback to no SSL at all, better not to try EC. Note an OpenSSL server using the ecdh *callback* could dynamically choose an appropriate curve (and possibly also key) based on what the client offers, but that's more work and for now requires poking directly in the SSL/session structure, although I think I remember a rumor that a better API is coming soon presumably 1.0.2. > 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. I don't think he says that. 1 para 1 says "later parameter[s] can negate the initial cipher suite choice, requiring returning to the suite list to try [another]". (Other) implementations might have this wrong, though. I'm also not sure what he means by "later"; everything is in the one ClientHello message, except possibly the issue he notes later about ECDSA and (E)ECDH with different (but both supported) curves; that isn't apparent until you get the (Server)Cert and ServerKX. In most cases that would make auth stronger or weaker than privacy, which isn't usually desirable, but might be. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
