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

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Tue, 15 Jun 2004, Bill Sommerfeld wrote:

> [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.

I'd prefer not to be running in either situation without knowing it.
Unfortunately, there are a lot of factors, and it's hard to say what
combinations are acceptable, so we don't try.  We also don't (can't)
prevent implementations from rejecting combinations they decide are
unacceptable.  It seems clear to me that listing the group14 method before
the group1 will result in better security and possibly better
interoperability.  That doesn't mean we need a REQUIREMENT here, but some
advice doesn't seem out of line.


> > 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.,).

Yes, that sounds like a good approach for an implementation to take.
Of course, DH-GEX makes this real fun -- you can't know what key size it
will produce.  In other words, yet another multi-level negotiation issue.

-- Jeff