Closed Bug 430875 Opened 13 years ago Closed 13 years ago
Document the policy for the order of cipher suites in SSL
_Implemented Ciphers .
1.25 KB, patch
|Details | Diff | Splinter Review|
1.91 KB, text/plain
In the past, the cipher suites in SSL_ImplementedCiphers were listed in decreasing order of security level, and at each security level, in decreasing order of performance. So we had: - ECDHE/DHE before others because ECDHE/DHE provide perfect forward secrecy - AES_256 before RC4_128 and AES_128 because AES_256 is more secure. - RC4_128 before AES_128 because RC4 is faster But with the addition of Camellia cipher suites, the ordering of cipher suites at each security level is no longer clear. The Camellia cipher suites are listed before RC4 and AES cipher suites. Nelson explained the rationale in bug 430769 comment 4. The rationale is not obvious and should be documented in a block comment before SSL_ImplementedCiphers. The appropriate ordering for the majority of NSS users is: - RC4 - AES - Camellia With my proposed ordering, servers that prefer Camellia have several tricks to make sure Camellia is negotiated with Firefox 3 Here are two: 1. Turn off AES_256 cipher suites. This will cause CAMELLIA_256 to be negotiated. 2. If the goal is to negotiate CAMELLIA_128 for better performance, turn off CAMELLIA_256, AES_256, RC4_128, and AES_128, but enable 3DES_EDE for interoperability with clients that don't support Camellia.
I tried to shorten Nelson's comment to one paragraph. Please make sure I capture the rationale accurately.
I think it is fair to say that, even before the addition of Camellia, there was an exception. RC4 was given priority over 128-bit ciphers, even though it is thought to be weaker than any other 128-bit ciphers. This was (and is) due to the fact that it was far more performance than any other 128-bit ciphers, and performance has always been very important to nearly all SSL users. We also rationalize that those who really want AES or DES could and would disable RC4, because implementation of AES and DES are so ubiquitous that disabling RC4 was not likely to prevent interoperability. Now, with Camellia, we a third motivation for prioritizing ciphers; one that is neither purely one of strength, not of performance, but of national pride. The situation with SEED, if it is ever introduced into NSS, will be the same. IMO, neither algorithm is likely to ever reach the level of ubiquity of the other ciphers we have now. The major, perhaps only, reason to use any of them will be national pride, IMO. IMO, Ultimately, the best way to deal with this, the way that will make the largest number of people happy, is to have user-selectable priority ordering of cipher suites. The problem with that is that the API and GUI for presenting that prioritization problem to a user or administrator is large, and IMO, products will be loath to do it. Firefox has already removed the GUI for even simple enabling and disabling of cipher suites, so I think it is highly unlikely that they would ever implement a GUI for prioritization of cipher suites. So, until we have user-selectable priority ordering, I think the way to go forward is to take those cipher suites that will be used predominantly for national pride, and disable them by default. The Cammeria suites are already disabled by default in NSS, but are enabled by default in PSM. Perhaps it would be appropriate to enable them by default in localized Japanese builds, and not in others. Comments?
Comment on attachment 317797 [details] [diff] [review] Document the current ordering of cipher suites >+ * The cipher suites are listed in decreasing order of security, and at >+ * each security level, in decreasing order of performance. >+ * >+ * The Camellia cipher suites are an exception to this rule. They are >+ * listed first at each security level because we want to make it easy >+ * for server admins who prefer to use Camellia to be able to negotiate >+ * Camellia without having to disable AES and RC4, which are needed for >+ * interoperability with clients that don't yet implement Camellia. I would change "easy" to "possible" or "feasible". Wan-Teh, do you find that change acceptable?
Yes, "possible" or "feasible" is fine. Thanks. Your proposal for national cipher suites sounds good to me. I'm not sure if Mozilla is set up to handle localized versions of files that contain preference settings rather than strings.
I think it's not a good idea to change product behavior based on locale. We should avoid that. Think about people who live in Japan and switch to an english locale for learning or business purposes. Think about people who are on vacation in a foreign country and use an Internet terminal to connect to a site in their home country. I don't understand why it is being proposed to disable cipher suites. Isn't this all about preference? Would it work to declare the rarely used ciphers as low priority ciphers, and use them only as a fallback, if the handshake couldn't agree on any other cipher?
Kai, Please read comment 2. The Japanese people want to give preference to their national cipher, espcially when dealing with their own government's servers. Because their national cipher is not yet ubiquitous, they cannot disable all other ciphers. They must allow other ciphers to work, too. But if their own cipher is not given preference, it will never be used, because those other ubiquitous ciphers will have preference. I opine that people in most other countries do not want to use it. So, it seems we can satisfy all people by doing all of these things: a) put the Japanese national cipher higher in preference to the other ciphers, b) disable it by default, c) only enable it for the Japanese, and those others who want it. What we have now is that the Japanese national cipher is enabled by default in PSM, so people who never heard of it, in (say) Europe, find themselves using it.
(In reply to comment #6) > The Japanese people want to give preference to their national cipher, Ok, I had missed that detail, thanks, but... > a) put the Japanese national cipher higher in preference to the other ciphers, > b) disable it by default, > c) only enable it for the Japanese, and those others who want it. ...is it really necessary to disable the ciphers? What about having the preference based on the locale? Could NSS have a runtime-adjustable 3-state-flag associated to each cipher, which has the values (0) default/standard (1) prefer (2) avoid This flag would get evulated after NSS checks for enabled/disabled. By default, NSS could treats all ciphers as (0) PSM could use some magic based on locale to configure the japanese cipher to (2) during init.
I rewrote the comment. How does this look?
Comment on attachment 319703 [details] [diff] [review] Document the current ordering of cipher suites, v2 r=nelson
Attachment #319703 - Flags: review?(nelson) → review+
I checked in the comment patch on the NSS trunk (NSS 3.12.1). Checking in sslenum.c; /cvsroot/mozilla/security/nss/lib/ssl/sslenum.c,v <-- sslenum.c new revision: 1.15; previous revision: 1.14 done FYI, here is IE7's ClientHello handshake message on Windows Vista.
This bug is paradoxical. Most people would intuitively list Camellia after AES and RC4. But after Nelson's explanation, I seem to "get it" and think our current ordering is right. Our current ordering does assume that only servers that prefer Camellia will turn on Camellia. The reality is that some servers that don't care either way also turn on Camellia, resulting in the surprise that Camellia is negotiated. So the ordering of national ciphers (if we ever add other national ciphers) will be interesting.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.12.1
see also bug 949564
You need to log in before you can comment on or make changes to this bug.