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

Stephen Kent <kent@bbn.com> Wed, 20 February 2008 22:52 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 m1KMqAfK023292 for <saag@PCH.mit.edu>; Wed, 20 Feb 2008 17:52:10 -0500
Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KMq0Mv013087 for <saag@mit.edu>; Wed, 20 Feb 2008 17:52:00 -0500 (EST)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id E26FCC4F75F for <saag@mit.edu>; Wed, 20 Feb 2008 17:51:39 -0500 (EST)
Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1JRxmt-0003lI-3R; Wed, 20 Feb 2008 17:51:39 -0500
Mime-Version: 1.0
Message-Id: <p06240500c3e239f72d4d@[10.84.131.31]>
In-Reply-To: <E1JRnFf-0008Uw-1D@wintermute01.cs.auckland.ac.nz>
References: <E1JRnFf-0008Uw-1D@wintermute01.cs.auckland.ac.nz>
Date: Wed, 20 Feb 2008 17:51:41 -0500
To: pgut001@cs.auckland.ac.nz
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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 22:52:15 -0000

At 12:36 AM +1300 2/21/08, Peter Gutmann wrote:
>mcgrew <mcgrew@cisco.com> writes:
>
>>Winston Churchill said that democracy is the worst form of government, except
>>for all of the others.  I think that the same is true for the FIPS-140
>>cryptomodule validation process ;-)
>
>I think it's more a case of the Politician's Fallacy:
>
>1. Something must be done.
>2. This is something.
>3. This must be done.
>
>It'd be interesting to see a study of the effectiveness in terms of finding
>security and interop problems of:

since I and others have pointed out several times that FIPS 140 eval 
has nothing to do with protocol interoperability, the reference to 
"interoo" above must be viewed purely within the context of crypto 
algorithms and modes thereof.

>
>A. A FIPS 140 eval.
>
>B. Running the code through Fortify/Coverity/whatever and completing a crypto
>    exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is
>    that's being used).
>
>in particular in terms of return for effort-involved.
>
>Peter.

FIPS 140 encompasses both hardware and software implementations of 
crypto modules. I see its greatest benefits in the context of the 
former. The process described above does not address hardware 
security module eval at all.

Steve