Weak DH primes and openssh

[Darren Tucker]

On Fri, May 22, 2015 at 10:33 AM, Damien Miller <djm at mindrot.org> wrote:

>
> On Thu, 21 May 2015, Matthew Vernon wrote:
>
> > Hi,
> >
> > You will be aware of https://weakdh.org/ by now, I presume; the
> > take-home seems to be that 1024-bit DH primes might well be too weak.
> > I'm wondering what (if anything!) you propose to do about this issue,
> > and what Debian might do for our users?
>
> I don't think much needs to be done: OpenSSH has preferred ECDH, and
> before that DH group-exchange with regularly refreshed modp groups for
> over a decade,


My intent was to refresh the groups for every release, but for several
reasons I haven't been consistent.  I am currently generating a new set.


> so the diffie-hellman-group1-sha1 mode is only ever used
> for compatibility with legacy implementations.
>
> While it is still offered (only by the client), it is offered last
> in preference and will never be selected if the client and server
> support better options. SSH's key exchange protocol AFAIK stronger than
> SSL/TLS's and forcing a downgrade requires breaking both the DH exchange
> and the hostkey algorithm in more or less real time.
>
> We do plan on dropping diffie-hellman-group1-sha1 from the default
> client offer later this year. We dropped it from servers a few releases
> ago.
>
> As for what Debian (and other distribtors) can do: IMO the best thing is
> to aggressively backport recent releases of OpenSSH to older supported
> releases of your operating systems. We've been trying to modernise the
> crypto across the 6.x releases as fast as we can without breaking stuff.
>
> > openssh already prefers ECDH, which must reduce the impact somewhat,
> > although the main Windows client (PuTTY) doesn't support ECDH yet. But
> > openssh does still offer diffie-hellman-group1-sha1 (uses a 1024-bit
> > group) and diffie-hellman-group14-sha1 (uses a 2047-bit group), which
> > must be considered a bit suspect? Of course RFC4253 says implementations
> > MUST offer these...
>

Note that PuTTY does do Diffie-Hellman Group Exchange, but until very
recently (ie after their 0.64 release) they didn't do the one that was
actually standardized in RFC4419.  OpenSSH recently removed support for
that non-standard one and as a result we don't offer DHGEX to PuTTY
versions <= 0.64 so they'll fall back to group14 (2k bit fix group).


> We'll be violating a few "MUST" clauses in the 7.0 release in the
> interests of security, including turning off group1 by default.

[...]

> > Would it be sensible to remove the <2047 moduli? Generating the larger
> > ones is quite time-consuming on non-specialist kit, which would seem to
> > argue against re-generating them on users' machines.
>

Currently, generating the 8kbit groups takes about 12 hours on a fairly
beefy 8 core x86-64 machine.  Anything slower, with fewer cores or bits
would take a lot longer.

Generating just the 1kbit groups takes about an hour on a 500MHz Pentium
class chip of the type found in smallish x86 embedded systems. (Out of
curiosity I fed the 8k candidate list to the same machine: it currently
estimates it'll take 281 days).

Darren can chime in here, but I don't think anything <2047 will actually
> be used since he updated dh.c:dh_estimate() a few years ago.
>

That's only true for OpenSSH clients.  PuTTY does this in their ssh.c:

s->pbits = 512 << ((s->nbits - 1) / 64);

which means that it'll ask for 1024, 2048 and 4906 bit groups for 128 bit,
192 bit and 256 bit ciphers respectively (ie equivalent to what OpenSSH did
prior to [1], which is a lot less than current recommendations[2].  That
said the development versions also have ecdh which they use in preference
to DH-GEX.

Anyway those older PuTTYs will be around for a while, maybe we should be
removing the 1024 bit groups from the moduli file?  For it to have much
impact it'd need to happen on the older OpenSSH servers because the current
ones don't offer DH-GEX to old PuTTY versions for the reasons above.

[1]
https://anongit.mindrot.org/openssh.git/commit/dh.c?id=df62d71e64d29d1054e7a53d1a801075ef70335f
)
[2]
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.