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.
- [saag] Algorithms/modes requested by users/custom… Randall Atkinson
- Re: [saag] Algorithms/modes requested by users/cu… Paul Hoffman
- Re: [saag] Algorithms/modes requested by users/cu… Randall Atkinson
- Re: [saag] Algorithms/modes requested by users/cu… Stephen Kent
- Re: [saag] Algorithms/modes requested by users/cu… Randall Atkinson
- Re: [saag] Algorithms/modes requested by users/cu… Paul Hoffman
- Re: [saag] Algorithms/modes requested by users/cu… Paul Hoffman
- Re: [saag] Algorithms/modes requested by users/cu… Jack Lloyd
- Re: [saag] Algorithms/modes requested by users/cu… Paul Hoffman
- Re: [saag] Algorithms/modes requested by users/cu… mcgrew
- Re: [saag] Algorithms/modes requested by users/cu… Stephen Kent
- Re: [saag] Algorithms/modes requested by users/cu… Jon Callas
- Re: [saag] Algorithms/modes requested by users/cu… Peter Gutmann
- Re: [saag] Algorithms/modes requested by users/cu… Peter Gutmann
- Re: [saag] Algorithms/modes requested by users/cu… Steven M. Bellovin
- Re: [saag] Algorithms/modes requested by users/cu… Peter Gutmann
- Re: [saag] Algorithms/modes requested by users/cu… Santosh Chokhani
- Re: [saag] Algorithms/modes requested by users/cu… Santosh Chokhani
- Re: [saag] Algorithms/modes requested by users/cu… Randall Atkinson
- Re: [saag] Algorithms/modes requested by users/cu… Santosh Chokhani
- Re: [saag] Algorithms/modes requested by users/cu… Randall Atkinson
- Re: [saag] Algorithms/modes requested by users/cu… Santosh Chokhani
- Re: [saag] Algorithms/modes requested by users/cu… Randall Atkinson
- Re: [saag] Algorithms/modes requested by users/cu… Santosh Chokhani
- Re: [saag] Algorithms/modes requested by users/cu… Jon Callas
- Re: [saag] Algorithms/modes requested by users/cu… Stephen Kent
- Re: [saag] Algorithms/modes requested by users/cu… mcgrew
- Re: [saag] Algorithms/modes requested by users/cu… Vishwas Manral
- Re: [saag] Algorithms/modes requested by users/cu… Peter Gutmann
- Re: [saag] Algorithms/modes requested by users/cu… Santosh Chokhani
- Re: [saag] Algorithms/modes requested by users/cu… Peter Gutmann
- Re: [saag] Algorithms/modes requested by users/cu… Santosh Chokhani
- Re: [saag] Algorithms/modes requested by users/cu… Stephen Kent
- Re: [saag] Algorithms/modes requested by users/cu… Peter Gutmann
- Re: [saag] Algorithms/modes requested by users/cu… Ben Laurie
- Re: [saag] Algorithms/modes requested by users/cu… Santosh Chokhani
- Re: [saag] Algorithms/modes requested by users/cu… Santosh Chokhani