I forwarded this enhancement request to upstream at
https://bugzilla.mozilla.org/show_bug.cgi?id=467372

I believe we should provide a separate PKCS #11 module and use NSS's crypto algorithm agnostic code to access it. The main thing missing from the agnostic code is adding an SSL cipher to the mix, but this does not seem to be needed.

One thing that does need to be added is a new PKCS #11 mechanism for this cipher suite. If someone who is familiar with the cipher  wants to propose a PKCS #11 mechanism I'd be happy to review the proposal and pass it on to the PKCS #11 working group.

NOTE: This is not a FIPS compatible cipher, therefore it must be turned off in FIPS mode. This means anything which *REQUIRES* (as opposed to *allows*) this cipher will not be FIPS validatable. I strongly urge the OpenAIS team to make sure that there is a FIPS validated alternative that can be selected (e.i. AES). As long as you have that, then providing SOBER-128 as a separately installed PKCS #11 module to NSS for the non-FIPS compatibility case is not a problem.

bob

NOTE2: SOBER-128 MAC has been broken. This is another reason to make sure you have some cipher agility, and in particular can support well tested and evaluated ciphers like AES.

bob

We don't use the MAC feature of sober128 since it has been proven failed.  We use the PRNG feature which remains secure and use SHA1 and HMAC as our message authenticator.

We can have no agility in regards to crypto algorithms because of a need to never break wire compatability.

We also have performance requirements which AES does not meet because it is terribly slow.

Regards
-steve

Adding alternative algorithms and potentially automatic negotiation does not break wire compatibility, does it?

I have investigated this feature in detail and outlined a schedule and technology several months ago.  We need a feature called "algorithm agility" which for the moment is not in the current upstream roadmap or rhel schedule.  Basically how it works is at the end of each packet we transmit on the wire, we send a "algorithm id" which is a number.  Since it is at the end of the packet it doesn't break wire compatibility as long as all nodes still continue to use algorithm 0 (the original).

number 0 is the current methodology, whereas number 1 would be an nss implementation, number 2 would be higher level nss implementation when nss 1 algorithms become compromised, etc.

On receipt of the packet, the appropriate decryption and authentication algorithm is used to decrypt the packet.  Transmit encryption algorithm of packets is controlled by a config option which is also dynamically configurable via a C API.

The user would use this technique to upgrade their nodes:
1.  user rolls all nodes from openais-0.80.X to corosync which is configured uing "algorithm 0" (the current algorithm) as the default transmit algorithm.
2.  User runs corosync-cfgtool or cman_tool which tells entire cluster to use "algorithm 1" for all new transmits after all nodes are rolled
3.  Existing corosync instances start using algorithm 1 (corosync is implemented to understand 0 and 1).

When a packet is received, its id is checked and the appropriate decryption algorithm is used based upon the id at the end of the packet.  This is localized to 1 C file, called "totemnet.c".

The first step is the algorithm agility of putting the identifier at the end of the packet and have corosync honor this identifier internally.  This provides the agility portion of the feature.

Then later we could roll out a new upgrade to corosync with NSS support and transition the users to different encryption algorithms.

I have provided management and product marketing with schedules for this technology and given other features and the lack of losing design wins because of the current implementation, it would appear it was prioritized lower and fell below the line given current resources.

There is no way to do auto negotiation without breaking wire compat without using the current set of algorithms so if full nss support is desired sober must be implemented in nss and there will be schedule impacts on cluster3 (our team is running at capacity and still behind schedule).

Regards
-steve

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.