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

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

On 15 Jun 2004, Niels Möller wrote:

> I'd find it easier to accept a general recommendation that if there
> are no other particular reason to prefer a certain algorithm over the
> other, clients should list algorithms ordered by strength, strongest
> first. Such a recommendation applies equally to all of the key exchange,
> host key, encryption and mac algorithm lists.

Sure, that seems like a resonable recommendation to make.


> Comments on particular algorithms seem out of place. If we really need
> that, the security considerations section of the transport draft seems
> like more natural place to me.

The transport draft doesn't really have a security considerations section.
All the security considerations are collected in the architecture draft,
just as we collected all the IANA considerations in one place.



> > On further reflection, I think it gets even more fun...
> > For some symmetric ciphers, group1 will be good enough.
> > For others, it will not.
>
> > What this means is that we should avoid selecting a cipher for which
> > the kex does not provide enough keying material.
>
> I don't buy this reasoning at all. The security requirements are
> determined by the context in which the connection is made, not by the
> key size of negotiated ciphers.

Yeah, OK.  The approach Bill describes makes a lot more sense.  And in any
case, it can't be anything other than a means of deciding what methods to
offer and in what order, which is entirely a matter of implementation and
local policy.

> And I agree with Bill that if we want to replace preferences of the
> form "I want group14 and aes256" (like in the implementations I'm
> aware of) with preferences of the form "I want at least 100-bit
> security", then that's excellent. It can be implemented in servers and
> clients, and in all cases it affects *which* algorithms are listed,
> not their order. As long as only algorithms that have adequate
> security are listed, order doesn't matter.

Yes.  Now that it's been suggested, I'd love to see an implementation or
three actually do this.