Closed Bug 430875 Opened 16 years ago Closed 16 years ago

Document the policy for the order of cipher suites in SSL_ImplementedCiphers.


(NSS :: Libraries, defect)

Not set


(Not tracked)



(Reporter: wtc, Unassigned)



(2 files, 2 obsolete files)

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
- 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
- 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
Attachment #317794 - Flags: review?(nelson)
I tried to shorten Nelson's comment to one paragraph.  Please make sure
I capture the rationale accurately.
Attachment #317797 - Flags: review?(nelson)
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.  

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. 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?
Attachment #317794 - Attachment is obsolete: true
Attachment #317797 - Attachment is obsolete: true
Attachment #319703 - Flags: review?(nelson)
Attachment #317794 - Flags: review?(nelson)
Attachment #317797 - Flags: review?(nelson)
Comment on attachment 319703 [details] [diff] [review]
Document the current ordering of cipher suites, v2

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

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.
Closed: 16 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.