445162 - Package a FIPS certified build of NSS with Firefox 3

Status: RESOLVED FIXED

(Firefox Build System :: General, enhancement)

Description

[Tim Miller]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; MS-RTC LM 8)
Build Identifier: 3.12

Current builds of NSS use softtoken3 version 3.12.0, but the last FIPS-certified version is 3.11.4.  A custom build of Firefox using NSS 3.12 linked with libsofttoken3 3.11.4 is available on RHEL and Fedora, but is not generally available for other platforms.

This issue limits NSS use in the US Federal governement, which must have FIPS 140-2 compliance.  A compatibility mode which specially loads the FIPS-compliant module(s) when checked would be ideal.

Reproducible: Always

Steps to Reproduce:
N/A
Actual Results:  
N/A

Expected Results:  
N/A

N/A

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

What are you requesting OF NSS ?

NSS 3.12 needs to be FIPS evaluated, and I expect it will be, some day.

It is possible, as Red Hat has shown, for integrators to assemble a 
Franken-NSS, an NSS that is a mixture of components from various existing
releases of NSS, that includes an older FIPS-validated NSS components. 

Perhaps you are requesting that Firefox release a version with such an 
Franken-NSS ?   But that is a request of Firefox, not of NSS. 
Firefox releases its own builds of NSS, that are not built by the NSS 
group, nor QA'ed by the NSS group.

Is this request simply filed against the wrong product?
Should we change it into a Firefox bug?

Comment 2

[Tim Miller]

I'd prefer that this remain as an NSS issue.  Changing this report to log against FF is fine as far as it goes, but the issue is relevant for all NSS-dependent applications (TB, Evolution, etc.) in the Federal space, so should be solved at the NSS layer.  In addition, this is *not* a one-time issue; it will arise every time the there is a discrepency between the currently validated modules and the currently shipping module.

What I'm requesting of NSS is to provide a means by which a shipping version can load FIPS 140 validated modules whenever the shipping modules are not validated.  This is a requirement for all US Federal government users as well as most contractors dealing with the US Federal government.  Such a mode will address FIPS requirements whenever the shipping modules are not yet validated.

I note that the NIST cryptval list shows Red Hat currently has an NSS version under test, but the list doesn't show which version this is.  Hopefully it's 3.12.0.  

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Please cite a URL for any NSS version currently under test.  
I believe there are NO FIPS evaluations of NSS currently underway.
Such things are very coordinated among the vendors, due to the cost involved.

Comment 4

[Tim Miller]

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140InProcess.pdf

Page 10, line 7, Red Hat Enterprise Linux Network Security Services (NSS) Cryptographic Module is listed as implementation under test (which means, at a minimum, that a contract with a NIAP lab has been signed :).

Note that the most recent actual certificates are #815 and #814, which are for NSS 3.11.4:

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm

So I presume that the current IUT is 3.11.4 < x <= 3.12.0.  If the current IUT is *not* 3.12.0 (or is *not* intended for all platforms), then it only highlights the need for this feature.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Interesting to note that the 07-31-2008 version of 
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140InProcess.pdf
does not list an NSS cryptographic module among the modules "under test"
for Red Hat.  I'm surprised the list is so fluid.

Comment 6

[Robert Relyea]

Hi Tim,

That is simple a revalidation of softoken 3.11.4 on a new platform. Red Hat wanted to make a stronger than 'Vendor Affirmed' statement on it's flagship OS.

bob

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

This RFE needs to be shaped into a clear picture of what the NSS deliverable
would be that would satisfy it, or else it needs to be changed into an RFE 
for some other product (such as Firefox) that ships NSS (or be closed).  

NSS will continue to develop new versions, including new versions of softoken 
and freebl (the FIPS validated components).  Naturally, newly developed 
versions of NSS's softoken will not be FIPS validated instantaneously, so 
there will be a lag time between the introduction of new versions of softoken
and subsequent announcement of FIPS evaluations of them.  

This bug seems to request that NSS be always built in such a way that there 
are always available two full versions of the softoken: the new version and 
the most recently FIPS evaluated version, and that NSS offer some "mode" for 
switching between them.  Perhaps other designs would satisfy this request.
That needs to be clarified.

I can tell you with certainty that there are numerous products that use NSS 
(and are developed by sponsors of NSS development) that would refuse to ship
a single product package with two NSS softokens.  I think Firefox is one of 
them.

It seems clear (indeed, obvious) to me that the choice of whether to ship a 
product with 
a) a current latest softoken, or 
b) an older FIPS validated softoken, or
c) both 
is a product packaging decision to be made by the products that include NSS,
and not by the NSS team itself.  And the logical conclusion of that is that 
this "FIPS compatibility mode" is a feature of products that package NSS,
not a feature of NSS (certainly not a feature of all distributions of NSS).

Don't try to tell me that US Government customers must always have the FIPS
validated version, with no ifs ands or buts.  There are US Government customers who are running not the FIPS evaluated version (3.11.4) but a bug-fixed version 
(3.11.x, x>5) because they really need the bug fixes, and they have no qualms
about it.  

I *suspect* (as I suggested in comment 1) that this RFE is really asking that Mozilla always make available a version of the latest Firefox that includes a FIPS validated module.  That has been done for Firefox 2, see bug 419030.
See also bug 433062 and bug 431204.

I have no problem with any product that includes NSS deciding to do that, 
but I have a problem with saying that NSS must be built for all platforms 
so that a single build of NSS satisfies both the needs of people who want
the FIPS validated version (bugs and all) and the people who want the version
with the latest fixes and features.  Saying that *all* builds of NSS MUST 
include a FIPS validate version is simply out of the question, IMO.  

Comment 8

[Tim Miller]

If you can think of another way to satify the requirement, by all means propose one.

In re: U.S. Federal users running non-FIPS versions of NSS:  Yes, this happens; policy says they're not supposed to do it; and when caught, the offending product either brought into compliance on a short timeline or is replaced.  I've seen it happen.  I've been forced to alter entire programs of record as a result.

If nothing else the issue is causing undue confusion.  I've had to *downgrade* users to a compliant version of FF2 because of FIPS issues, and what I get back is a plaintive "But NSS is certified!"  Users don't understand the ins and outs of FIPS 140 compliance.

And what am I and the rest of the U.S. Fed-supporting world supposed to do when FF2 reaches end-of-support in 5 months?  Use IE?  I've got programs where that isn't an option because of other issues.

Fobbing this request off on the packaging product to adopt a FIPS/non-FIPS versioning scheme would force duplication of this bug request *all* NSS-using products.  While the big boys (FF, TB) may be manageable, what about the rest?  Why should this burden be placed on dozens of products when it can be solved right here, *once*, for everyone?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

It looks to me that a Firefox extension that supplies an alternative softoken
would solve this problem nicely for Firefox and Thunderbird.  It would have 
automatic updates, like the rest of firefox and thunderbird, and it would not 
add any to the size of the basic firefox and thunderbird downloads.  

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

This is a request from some representatives of US government agencies that 
Mozilla Corporation package a build of Firefox 3 that incorporates the 
FIPS validated softoken PKSC#11 module from NSS 3.11.4, the version of NSS 
used in Firefox 2, instead of NSS 3.12.1, the version developed for Firefox 3.  

The version that Mozilla chooses to incorporate into Firefox 3 is Mozilla's
decision.  

Whether MoCo wants to do that, or package the 3.11.4 softoken as an extension
(as suggested above), or none of the above, or something else entirely is up 
to MoCo folks.  

Comment 11

[Bob Lord]

The latest FF 3.5 builds now use a version of NSS that is under FIPS 140 review at NIST.  There is an internal DoD memo that permits users to use this version given that it strikes the right balance between formal validation and up-to-date browser security.

This issue is all but closed. I'm going to be a little aggressive and close it since the reporters are now able to use the latest FF bits.

Comment 12

[Tim Miller]

Bob--

Can you supply a reference for this alleged memo?  The *only* memo re: FF 3.5 I've seen is the approval for 3.5.4 use *by the DoD PKI RAs*--i.e., installed only on RA and LRA workstations--and nowhere else.

If this is the memo to which you refer, I'd like this issue re-opened.

-- Tim