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

pgut001@cs.auckland.ac.nz (Peter Gutmann) Wed, 20 February 2008 13:51 UTC

Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KDpKrF005230 for <saag@PCH.mit.edu>; Wed, 20 Feb 2008 08:51:20 -0500
Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KDp9AR026495 for <saag@mit.edu>; Wed, 20 Feb 2008 08:51:09 -0500 (EST)
Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mit.edu (Spam Firewall) with ESMTP id 2F3A4D66C28 for <saag@mit.edu>; Wed, 20 Feb 2008 08:50:47 -0500 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 508FD9C78E; Thu, 21 Feb 2008 02:50:46 +1300 (NZDT)
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sClDQVRjcD-U; Thu, 21 Feb 2008 02:50:46 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4A4CA9C783; Thu, 21 Feb 2008 02:50:45 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C569219EC0B7; Thu, 21 Feb 2008 02:50:42 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <pgut001@wintermute01.cs.auckland.ac.nz>) id 1JRpLO-0006MQ-Lc; Thu, 21 Feb 2008 02:50:42 +1300
From: pgut001@cs.auckland.ac.nz
To: pgut001@cs.auckland.ac.nz, smb@cs.columbia.edu
In-Reply-To: <20080220131048.55faab0b@cs.columbia.edu>
Message-Id: <E1JRpLO-0006MQ-Lc@wintermute01.cs.auckland.ac.nz>
Sender: pgut001 <pgut001@cs.auckland.ac.nz>
Date: Thu, 21 Feb 2008 02:50:42 +1300
X-Spam-Score: 0.00
X-Spam-Flag: NO
X-Scanned-By: MIMEDefang 2.42
Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com
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: Wed, 20 Feb 2008 13:51:20 -0000

"Steven M. Bellovin" <smb@cs.columbia.edu> writes:

>FIPS-140 is mostly about assurance of security, and not just correctness of
>the crypto.

Is it about assurance of security, or assurance of production of paperwork
showing the certification conditions have been met?  There have been plenty of
security advisories issued for CC and FIPS-140 evaluated products (and even
more not publicised but silently fixed in a certification-voiding manner).

>Given the really bad mistakes we've all seen -- things that would be caught
>by any decent outside evaluation -- what is the alternative? What is the
>*assurance* a customer has that the product is adequately secured?

Politician's Fallacy again: Is FIPS 140 really the best way to spend your
money?  If FIPS 140 is the answer now, why wasn't the Orange Book the answer
then?  What about giving the money to (picking a random name) Cigital and
saying "make sure this code is OK"?  What about giving the money to Dan
Bernstein and saying "implement this and make it secure"?  What about having
the code written by Germans and pen-tested by the French? [0].  We have no
hard data either way (although I'd put my money on Cigital and Dan to produce
the more secure product :-).  But simply saying "We must use FIPS 140...
just... well, just because!" is hardly a scientific approach to solving the
problem.

Peter.

[0] A very much under-exploited strategy in security evaluation.