+++ This bug was initially created as a clone of Bug #1036765 +++ After we ship a release with the patches for bug 1036765, we should remove the preferences that had their default values set to false in that patch.
Removing Camellia means leaving users with no strong alternative to AES. Hence, in case of a security issue with AES there's no way to react quickly. Removing support for 3DES is probably not a good idea either because there are still some IIS/6.0 systems out there that don't speak AES or Camellia. I found this bug after noticing that Firefox 33 doesn't speak Camellia with my webserver anymore although I configured it as the preferred cipher in order to get away from the AES monotony a bit. I'd prefer a more diverse set of cipher suites.
Assignee: nobody → brian
Target Milestone: mozilla35 → mozilla37
Compare this to the patch for bug 1036765. This is the same process we used for the previous batch of cipher suite support removal.
Attachment #8532360 - Flags: review?(dkeeler)
(In reply to Thomas Peters from comment #1) > Removing Camellia means leaving users with no strong alternative to AES. > Hence, in case of a security issue with AES there's no way to react quickly. > > I'd prefer a more diverse set of cipher suites. 1. Currently, NSS doesn't support any ECDHE cipher suites for Camellia. See bug 940119 about rectifying that. That bug is blocked on my review; I'll try to get the review done sometime before the end of the year. That bug must be fixed before Camellia can be reconsidered; even then, I'm not sure Mozilla wants to enable any Camellia cipher suites. 2. It seems there is more support for adding ChaCha20-Poly1305 cipher suites; see bug 917571. I think the addition of the ChaCha20-Poly1305 cipher suites will address your concern about relying on AES too much.
Status: NEW → ASSIGNED
Attachment #8532360 - Flags: review?(dkeeler) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.