Re: [saag] Algorithms/modes requested by users/customers

Randall Atkinson <rja@extremenetworks.com> Tue, 19 February 2008 15:35 UTC

Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JFZeXt015205 for <saag@PCH.mit.edu>; Tue, 19 Feb 2008 10:35:40 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1JFZVXb008340 for <saag@mit.edu>; Tue, 19 Feb 2008 10:35:32 -0500 (EST)
Received: from ussc-casht-p2.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id D06F4DDF61A for <saag@mit.edu>; Tue, 19 Feb 2008 10:35:10 -0500 (EST)
Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Tue, 19 Feb 2008 07:35:09 -0800
From: Randall Atkinson <rja@extremenetworks.com>
To: "saag@mit.edu" <saag@mit.edu>
Date: Tue, 19 Feb 2008 07:35:08 -0800
Thread-Topic: [saag] Algorithms/modes requested by users/customers
Thread-Index: AchzCkrWW2rvMNdgR4y9V+Rd88/V4AAADsK4
Message-ID: <8329C86009B2F24493D76B486146769A9429B7C6@USEXCHANGE.corp.extremenetworks.com>
References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> <p06240804c3de211f0592@[10.20.30.162]>, <p06240504c3e09559649c@[192.168.0.102]>
In-Reply-To: <p06240504c3e09559649c@[192.168.0.102]>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Spam-Score: 0.02
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1JFZeXt015205
Subject: Re: [saag] Algorithms/modes requested by users/customers
X-BeenThere: saag@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: IETF Security Area Advisory Group <saag.mit.edu>
List-Unsubscribe: <http://mailman.mit.edu/mailman/listinfo/saag>, <mailto:saag-request@mit.edu?subject=unsubscribe>
List-Archive: <http://mailman.mit.edu/pipermail/saag>
List-Post: <mailto:saag@mit.edu>
List-Help: <mailto:saag-request@mit.edu?subject=help>
List-Subscribe: <http://mailman.mit.edu/mailman/listinfo/saag>, <mailto:saag-request@mit.edu?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2008 15:35:40 -0000

Earlier, Steve Kent wrote:
% Also, if buyers believe that a device that "could be evaluated" is
% good enough, they are being rather naive.  Experience with the
% FIPS 140 program has shown that a significant fraction of of
% products submitted for evaluation fail the process.

The quoted text above is fully consistent with my information
(and my very limited personal experience) on this topic.

% Presumably a vendor submitting a product for evaluation
% believes that the product is ready, and will pass, otherwise the
% vendor is wasting money on the evaluation effort.

Some purchasers, including some US DoD components, do not
require that a product actually be FIPS-140 certified in order
for the purchaser to buy the product.  Instead, some purchasers,
including some US DoD components, only require that a product
be "in evaluation" on the NIST web site in order to bid/sell that
product.

This can incent some vendors to submit products for FIPS-140
evaluation in order to bid/sell the product -- even if the vendor
is unsure whether the product will pass that evaluation at that
point in time.  This last is a business decision based on various
business factors, and is not necessarily a technical decision.

Separately, there is substantial documentation required to pass a
FIPS-140 evaluation, and it is not crystal clear upfront what level
of detail on which topics is required to pass the evaluation.  So,
separate from the question of whether the product itself is ready,
there is usually substantial documentation work required of the
submitter after the formal FIPS-140 evaluation commences.

The one area where I have heard concerns expressed by many
implementers is that it can be difficult/time-consuming/expensive
to "RAMP" an approved product so that a later version is
approved formally under FIPS-140.  I don't know if this is an
actual process issue or merely a perceived issue.  At least one
implementer has commented to me that their latest FIPS-approved
firmware has known-bugs fixed in subsequent non-FIPS-approved
firmware because of (real or perceived) "RAMP" process issues.

% The fact that  many products fail evaluation (for good security
% reasons), tells me that a vendor's claim that a product
% "could be evaluated" is not much of an assurance.

Agreed.  And this point has been made to me by several different
commercial/financial firms.  It is not a coincidence that the
encryptor I use at my home has an actual FIPS-140 certificate,
nor that I use that system in FIPS mode.

(And at this point, I seem a bit far from the charter of the SAAG
list, but I'm not sure where followups should go.   My apologies
to any who viewed this as excessively off-topic.)

Yours,

Ran
rja@extremenetworks.com

DISCLAIMER:  I am employed by Extreme Networks, but I am never
authorised to speak for my employer.  The text from me above
is my own personal views/understanding, and must not be taken
as a position held by my employer.