RE: SOI QUESTIONS: 5.1-5.2

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

>   I don't find this acceptable.
>   1) in order to avoid permitting users to shoot themselves
> in the foot, some
>      GUI will have to *restrict* them to those ciphersuites.

The nice thing about GUI ciphersuites is that you could choose to implement
only the 2 MUST IMPLEMENT combinations and nothing else, and you would be
interoperable with everyone else, but other people could still implement the
feature however they want. (Unless the aim of ciphersuites is to cripple
everyone's implementation equally so that yours doesn't stand out for not
giving the user the choice.) Part of the purpose of GUI ciphersuites is to
give the user a convenient default configuration option. Of course they can
still shoot themself in the foot if they try hard enough. ("I though ESP
NULL was a block cipher...")

>   2) Given the above, how do I test all combinations?
>
>   Talk to your testing people on this.  Let them make the decision.

Our testers have a script for generating and negotiating every possible
combination of algorithms. Personally, I don't think black box testing of
this sort is very useful. It hearkens back to my previous example of the guy
who wanted to test his FPGA DES implementation by trying every single key. I
am more inclined to white box test all the important code paths. I would try
each algorithm at least once. I would make sure to get at least one case
where the keymat had to be stretched. I would try the largest key size to
make sure no one hardcoded a buffer somewhere.

Way back in the 80s (or perhaps even the 70s), someone invented the idea of
modularity. Modularity makes testing every possible combination a luxury,
rather than a necessity. The crypto code is first tested with known answer
tests. Then the packet transform code is tested with the assumption that the
crypto code works (perhaps using manual keying). Since the crypto is a black
box, what you are testing is code that allocates buffers and moves memory
around. A Neanderthal might "test" a gateway by first trying to eat it, then
setting it on fire and finally by evaluating its potential as a weapon. In
reality, random trial and error doesn't work so well. Proper testing
requires human judgement, a knowledge of what the product is suppose to do,
and some knowledge of how the code works internally.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Richardson
> Sent: Thursday, July 11, 2002 10:36 PM
> To: ipsec@lists.tislabs.com
> Subject: Re: SOI QUESTIONS: 5.1-5.2
>
>
>
> >>>>> "Andrew" == Andrew Krywaniuk
> <andrew.krywaniuk@alcatel.com> writes:
>     >> 5.2.A) Is it important to have predefined suites or a la
>     >> carte selection of
>     >> parameters?
>
>     Andrew> I prefer to have so-called "GUI ciphersuites"
> where we allow negotiation of
>     Andrew> parameters on the wire, but define names for a
> few specific combinations.
>     Andrew> These common names could then be used in a GUI to
> ensure easy configuration
>     Andrew> of heterogeneous networks. The problem with
> ciphersuites has traditionally
>     Andrew> been that not everyone is going to agree on every
> parameter. Ciphersuites
>     Andrew> will force us to accomodate the lowest common
> denominator (or perhaps the
>
>   I don't find this acceptable.
>   1) in order to avoid permitting users to shoot themselves
> in the foot, some
>      GUI will have to *restrict* them to those ciphersuites.
>
>   2) Given the above, how do I test all combinations?
>
>   Talk to your testing people on this.  Let them make the decision.
>
>   Suites rule.
>
> ]       ON HUMILITY: to err is human. To moo, bovine.
>   |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON
>   |net architect[
> ] mcr@sandelman.ottawa.on.ca
> http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another NetBSD/notebook using, kernel hacking,
> security guy");  [
>