[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 at vpnc.org] 
Sent: Tuesday, February 19, 2008 1:04 PM
To: Santosh Chokhani; Stephen Kent
Cc: saag at 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



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.