The IETF draft on "ECC cipher suites in TLS" defines several cipher suites using ECDHE-ECDSA and ECDHE-RSA key exchange mechanisms. Currently, the SSL server-side code in NSS uses a hardcoded value for the curve used to generate the ephemeral keys (see ssl3_CreateECDHEphemeralKeys(sslSocket *ss) in ssl3ecc.c). There ought be some sort of a callback mechanism that let's the application using the SSL server code to specify a curve.
Perhaps apps should be able to choose this, but some app/server developers think there are already way too many things they must configure with SSL. So, IMO, apps must not be required to choose this. There must be some reasonable default that gets chosen if the app doesn't choose it. Personally, I think it would be best to choose either: a) the same curve as used in the server's cert, or b) the smallest curve supported (believing that it is only ephemeral, after all).
(In reply to comment #1) I agree with your concern in general but the specific proposals have issues worth pointing out. > Personally, I think it would be best to choose either: > a) the same curve as used in the server's cert, or This wouldn't work for ECDHE-RSA ciphers because the server's cert has an RSA key. > b) the smallest curve supported (believing that it is only ephemeral, after > all). For now, I think choosing secp256r1 is a good option because it is a curve that will be supported in browsers we want to be interoperable with. Smaller curves are not likely to be widely supported. vipul
Assignee: wtchang → nelson
Severity: normal → enhancement
Version: unspecified → 3.11
Ideally, this curve should not become the weakest link, and it just needs to be as strong as the weakest link.
reducing to P2. I don't think we'd stop the release for the absence of this feature. I think it's enough to make a good automatic choice on behalf of the app, at least for the initial release. Let me know if you disagree. Also, let me know if you think that NSS is not presently making a good choice for the ECDHE curve by default. THAT would be P1, I think.
Priority: P1 → P2
I have a patch in bug 326482 which implements the scheme where the ECHDE key matches the ECDSA signing key, or an appropriate curve based on the RSA signing key. The code only needs to deal with the TLS curve extension (particularly in the case of the RSA signing key). bob
QA Contact: jason.m.reid → libraries
*** Bug 342557 has been marked as a duplicate of this bug. ***
Unsetting target milestone in unresolved bugs whose targets have passed.
Target Milestone: 3.12 → ---
Isn't this resolved now?
Indeed. This worked differently from the description in comment 0 for a while now and was fully resolved with allowing custom EC group preferences bug 1296239.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1296239
You need to log in before you can comment on or make changes to this bug.