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

"Santosh Chokhani" <SChokhani@cygnacom.com> Tue, 19 February 2008 18:16 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 m1JIGRkf021471 for <saag@PCH.mit.edu>; Tue, 19 Feb 2008 13:16:27 -0500
Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JIGHED013637 for <saag@mit.edu>; Tue, 19 Feb 2008 13:16:17 -0500 (EST)
Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id D68867913AC for <saag@mit.edu>; Tue, 19 Feb 2008 13:13:08 -0500 (EST)
Received: (qmail 3499 invoked from network); 19 Feb 2008 18:05:36 -0000
Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 19 Feb 2008 18:05:36 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 19 Feb 2008 18:05:36 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 19 Feb 2008 13:13:06 -0500
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D483C4E9D@scygexch1.cygnacom.com>
in-reply-to: <p06240806c3e0c794447c@[10.20.30.152]>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] Algorithms/modes requested by users/customers
Thread-Index: AchzIeEnGWfnkW1lSVWs0LiLJakuowAAGwGw
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> <p06240806c3e0c794447c@[10.20.30.152]>
From: Santosh Chokhani <SChokhani@cygnacom.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Stephen Kent <kent@bbn.com>
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 m1JIGRkf021471
X-Mailman-Approved-At: Wed, 20 Feb 2008 10:05:23 -0500
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:16:27 -0000

Paul,

These statements are not based on "feelings".  They are based on
experience of doing third party testing such as TPEP (TCSEC), TTAP
(TCSEC and CC), CC testing and FIPS since 1987 and being involved in the
FIPS program since its pre-formative days.

If there are specific concerns, I would be happy to look into those.

My general observation is that vendors do not assign their engineers to
these efforts and there is a dearth of qualified testers, resulting in
blind leading the blind.

If you get a good tester, he/she will force the vendor to provide a good
engineering answer and many of the general issues you are mentioning
will get tackled right.

I would recommend that VPNC members/vendors have good engineers making
sound arguments.  Most of the times, that works.

-----Original Message-----
From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] 
Sent: Tuesday, February 19, 2008 1:04 PM
To: Santosh Chokhani; Stephen Kent
Cc: saag@mit.edu; Randall Atkinson
Subject: RE: [saag] Algorithms/modes requested by users/customers

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