Re: Last ditch proposal for crypto suites

[Jan Vilhuber <vilhuber@cisco.com>]

I'm wondering whether a hybrid approach would be reasonable:

1) Define suites for ciphers+mac (i.e. 3des-sha1, aes-sha2 whatever).
1') Tie phase 1 and phase 2 suites together, i.e. a suite applies to
both (drawback: You now can't negotiate des for phase 1 and 3des for
phase 2; seems there are those that want this).
2) define a separate 'thing' for the phase 1 authentication.
3) Not sure where to put compression...

So you would propose:

suite A (3des-sha1)
authentication pre-shared

or

suite A (3des-sha1)
rsa

This may prevent some of the combinatorial explosion of having
3des-sha-pre-share and 3des-sha-rsa and 3des-sha-dsa, and instead you
only have pre-share and 3des-sha as separate entities.

*donning flame proof bathrobe, which I'm sure arthur dent would have
 loved to have*

jan

P.S. I guess this really boils down to having three sets of
parameters:

1) joint phase 1 and phase 2 cipher suite
2) phase 1 ONLY settings (authentication... anything else?)
3) phase 2 ONLY settings (above and beyind ciphers, i.e. compression?
Anything else?)


On Fri, 30 Aug 2002, Scott G. Kelly wrote:

> "Hallam-Baker, Phillip" wrote:
> >
> > > I think the original argument against suites came from observing how
> > > many SSL had.
> >
> > I think that that was largely the result of TLS being specified at a time
> > when RSA was still encumbered and bona-fide MAC functions had not been
> > developed.
> >
> > We are talking about 3 MUST suites and 2 MAY suites maximum. IKE1 had 9
> > encryption ciphers alone.
>
> I'm not sure how (or if) we actually arrived this conclusion, and I
> don't see how we can possibly make this work with just 3 suites. For
> example, I know the pk vendors would like to see nothing but RSA-based
> authentication mandated, but until the market fully embraces public key
> technology, we must have preshared key support.
>
> Whether we choose suites, a la carte, or both, there will be practical
> reasons for supporting multiple authentication, encryption, and
> integrity mechanisms. Choosing suites doesn't, in and of itself,
> automagically reduce the number of algorithmic combinations we will
> provide support for; it simply reduces the number of ways in which each
> combination can be expressed, and thereby significantly simplifies the
> protocol.
>
> I should make clear that I agree with the general notion that we should
> try to reasonably limit the number of suites which are IANA-defined.
> However, we must be realistic and pragmatic.
>
> Scott
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

http://www.eff.org/cafe