On Fri, May 22, 2015 at 10:33 AM, Damien Miller <djm@xxxxxxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
