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

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 19 February 2008 18:05 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 m1JI5774017621 for <saag@PCH.mit.edu>; Tue, 19 Feb 2008 13:05:07 -0500
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JI4uI2023267 for <saag@mit.edu>; Tue, 19 Feb 2008 13:04:57 -0500 (EST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7617DDA0F82 for <saag@mit.edu>; Tue, 19 Feb 2008 13:04:35 -0500 (EST)
Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JI4Fjl086137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 11:04:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240806c3e0c794447c@[10.20.30.152]>
In-Reply-To: <FAD1CF17F2A45B43ADE04E140BA83D483C4E93@scygexch1.cygnacom.com>
References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> <p06240804c3de211f0592@[10.20.30.162]><p06240504c3e09559649c@[192.168.0.10 2]> <p06240804c3e0ad5d1fa4@[10.20.30.152]> <FAD1CF17F2A45B43ADE04E140BA83D483C4E93@scygexch1.cygnacom.com>
Date: Tue, 19 Feb 2008 10:04:12 -0800
To: Santosh Chokhani <SChokhani@cygnacom.com>, Stephen Kent <kent@bbn.com>
From: Paul Hoffman <paul.hoffman@vpnc.org>
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, Randall Atkinson <rja@extremenetworks.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: Tue, 19 Feb 2008 18:05:07 -0000

At 11:49 AM -0500 2/19/08, Santosh Chokhani wrote:
>On the issue of restart, that is misunderstanding on Paul's part.  There
>is no restart.

Ahem. I am reporting what the members of VPNC report to me. They are 
the vendors in the testing, not me. I have heard this from multiple 
vendors. If I was not clear that I was reporting what others said, I 
apologize.

>Generally, problem is fixed and you pick up that point.

Not to be too picky, but how can you say "generally" without seeing 
every test that was stopped? Maybe you have not had this problem, but 
others say they have.

>Subjective tests seems to be misunderstanding on Paul's part.  Having
>been in the Orange Book, CC and FIPS process, I as validator, tester,
>and certifier as well as vendor generally rue about rigidness of the
>standard and lack of subjective judgment on the part of the tester or
>lack of subjective latitude to vendors.

If you, as a tester, feel that there are no subjective parts of the 
test process, that's fine. Some/many people who are being tested 
disagree with you.

>FIPS 140 has specific guidelines on how to deal with minor incremental
>changes that helps reduce cost and calendar time.

Great! It does not seem to have gotten through to the vendors 
themselves as "inexpensive enough" or "fast enough". As a tester, you 
may have a different view.

>The standard is NOT a protocol standard.  It does verify the algorithm
>implementations and thus, FIPS validated algorithms can interoperate.

Quite true.

>In terms of low end devices, 20-30K for level 1 testing amortized over
>devices does not seem too onerous.

...to you. Others disagree, both on the financial cost, and 
particularly on the cost of elapsed time before customers can use the 
latest release from a vendor.

>I do not understand what Paul refers to as silly modes.  The module
>being FIPS validated must use FIPS validated or recognized algorithms
>for a given crypto service.  That seems like a good thing to me.

That is a good thing; it is also not what I was talking about. There 
is disagreement about what needs to be in a "FIPS mode", and whether 
the shipped product needs to allow "FIPS mode" to be enabled, and if 
so, how.

Again: I am reporting what I hear from many VPNC members over many 
years. You as a single vendor and/or tester might feel differently; 
your feeling does not invalidate the views of others.

--Paul Hoffman, Director
--VPN Consortium