Re: [psg.com #460] IESG - Transport - Oakley

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

[wg chair hat off].

We have to cope with a grab bag of algorithms at seemingly random
bit-strengths that don't necessarily fit together well if you try to
tune one to match the other.  I think that's the wrong attitude..

> What this means is that we should avoid selecting a cipher for which the 
> kex does not provide enough keying material.  

Reality check:

so, if the kex provides N bits, and you have a choice between a cipher
with keysize N/2 and keysize 2N, you would prefer the N/2-bit cipher
to running a 2N bit cipher with what is effectively a stretched N-bit
key?

The latter is obviously stronger against brute force attacks.  

> Or, more likely, we should avoid selecting a kex that does not
> provide enough keying material for the cipher we're going to use.
> Unfortunately, that would mean changing the algorithm selection
> rules, and I think it's too late to do that without a really good
> reason.

Going outside the scope of the IETF spec and deep into
quality-of-implementation space:

I'd rather see an application-level requirement for a specific
strength-in-bits.  If the kex generates enough bits, add it to the
acceptable list.  Likewise, if the symmetric algorithm is
N-bits-strong against all known attacks, add it to the list.

Then sort the lists by the performance metric of your choice
(throughput, latency, etc.,).  

						- Bill