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

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

On Tuesday, June 15, 2004 19:54:23 +0200 Niels Möller 
<nisse%lysator.liu.se@localhost> wrote:

> Chris Lonvick <clonvick%cisco.com@localhost> writes:

> > [ARCHITECTURE]  (2 changes needed)
> >
> > (1)
> > Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically
> > names diffie-hellman-group1-sha1.  This can be changed to "the key
> > exchange methods described in Section 8.1 in [TRANS]".
>
> Or just make it clear that diffie-hellman-group1-sha1 is an *example* of
> a specified key exchange method that have PFS-properties.
>
> > A new section 9.2.8 will be needed to discuss the ordering of key
> > exchange method proposals.  Currently, [TRANS] Section 7.1 states:
>
> I don't think this is needed at all. To me, the rules are the same as
> for all the other algorithm lists: Each client lists the algorithms it
> is willing to use, in the client's preferred order.

I'm not sure if you're commenting here on the proposed ARCH/9.2.8 text, or 
on the TRANS/7.1 text which Chris actually quoted at this point.  The 
quoted text was existing text from the transport draft, and is the 
normative description of the algorithm selection rules for key exchange 
(which are a bit more complicated than for others).  It needn't be 
duplicated in the architecture document, but I don't think that was being 
proposed.



> >    As stated in Section 7.1 of [TRANS], each device will send a list of
> >    methods for key exchange.  The preferred method will be the first in
> >    the list.  The preferred method SHOULD be the cryptographically
> >    strongest method, and the method most likely to satisfy the conditions
> >    stated in that section.  Of the two methods defined in Section 8.1 of
> >    [TRANS], diffie-hellman-group14-sha1 MUST be listed before
> >    diffie-hellman-group1-sha1 in the kex list.  Implementors are
> >    encouraged to review current literature to decide upon the order of
> >    any other locally defined kex methods listed in the kex proposal.
>
> "You can get this nice car in any color of your choice, as long as
> your choice is black", or "You must put the algorithm you prefer
> first, and you MUST prefer the one I say". It makes the word "prefer"
> meaningless.

I'm inclined to agree; MUST is too strong.



> If we, now or in the future, really want to deprecate
> diffie-hellman-group1-sha1, the right way to do that is to *formally*
> deprecate it, by changing

Careful.  REQUIRED means must-implement.  DEPRECATED doesn't mean anything, 
requirements-wise.  We want people to implement group1 but not prefer it. 
We do not want people not to implement it, at least now.



> the text, and in particular, the architecture document is *not* the
> right place.

The security considerations section is a perfectly reasonable place for 
advice on algorithm selection, to the extent that we want to give such 
advice.  I'm still inclined to think we should provide some advice like 
"prefer diffie-hellman-group14-sha1".

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

As it stands now, we could end up negotiating diffie-hellman-group1-sha1 
and, say, aes256-cbc, which woule not be very good.  So, IMHO there's a
good security reason for giving advice about selecting a larger group.



-- Jeff