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

[nisse%lysator.liu.se@localhost (Niels Möller)]

Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:

> It might be desirable to RECOMMEND or even REQUIRE that
> diffie-hellman-group14-sha1 be listed _before_
> diffie-hellman-group1-sha1, so that its use is preferred when both
> sides support it.

I don't think such a recommendation or requirement is appropriate at
all; algorithm selection is an implementation/local configuration
issue. Saying that both groups MUST be supported is clear enough, I'd
expect that all implementations except possibly very constrained ones
will prefer group14 over group1, as soon as it's implemented and
tested.

As I understand it, the goal of this wg since the beginning has been
that the specified algorithms, and in particular, all RECOMMENDED or
REQUIRED algorithms, should be *good enough* from a security
perspective. So that users can choose freely between algorithms for
whatever reasons they have, without compromising security by mistake.
A user should not be able to break security by using ordinary
algorithm selection options[2], and then the default algorithm
preferences in implementations shouldn't matter either.

No matter what the specification and implementations do, there will
always be some link that is weakest (and that could well be something
out of scope of the protocol spec, like the backup routines for the
seedfile of the randomness generator, whatever). Our job is to ensure
that the weakest link is reasonably strong, not to spell out the
relative strength of each link.

Now I'm afraid I'm not up to date on the state of art in computing
discrete logarithms. If it's the case that group1 really is considered
insecure, then the spec should grandfather[1] its use (in much the
same way as we would discourage plain DES, if it had ever appeared as
a MUST in te specification), but as far as I'm aware, that's not the
case.

Bottom line: Just specify diffie-hellman-group14-sha1.

Regards,
/Niels

--
[1] Thanks to our chair Bill who explained the meaning of this very
useful verb a while ago.

[2] And letting users prefer "none" at all in an implementation
degrades the user interface. I should probably stop supporting it, or
at least rename the command line option from -c none to
--I-dont-want-any-security-and-I-know-what-I-am-doing.