Hi Darren, Many thanks for your response. Darren Tucker <dtucker@xxxxxxxxxx> writes: > On Sat, Jul 25, 2015 at 9:25 AM, Mark D. Baushke <mdb@xxxxxxxxxxx> wrote: > > > Greetings, > > > > Given the weakness with Diffie-Hellman modp groups less than 2048, is it > > time to bump the suggested 1024 bit minimum value from the RFC 4419 to a > > more current 2048 value for OpenSSH 7.0? > > > > DH_GRP_MIN is used for 2 things: > a) the client's minimum acceptable group size sent in the DH-GEX request. > b) the lower bound of the group size picked out of the moduli file. > > For a), the OpenSSH client has asked for preferred sizes no less that 2k > bits for a couple of years [1]. Changing the minimum in this case would > have no effect on (RFC compliant) servers that have groups >= 2k, and would > probably cause a connection failure on ones that do not. Regarding RFC compliant servers, RFC 4419 specifies the 1024 bit minimum as a 'SHOULD' value rather than a 'MUST' value. If we do care that the default needs to be able to be adjusted by the SSH client AND the SSH server, then perhaps it needs to be a configuration option that best meets the paranoia of the user and the site administrator? fwiw: NIST SP 800-131A[3] (see Table 4) currently wants the minimum Diffie-Hellman Group to be enforced as a minimum of 2048 bits. Using less than 2048 bit DH primes would not be a best practice as far as the NIST folks are concerned. [3] http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf or its draft replacement http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf > For b), we recently removed the 1k groups from the moduli file, so the > minimum that can be offered is 1.5 kbit. Yes. This was a good change. I am not sure that removing primes less than 2048 bit would not be even better... That said, because I care about NIST SP 800-56Ar2[4] section 5.5.1.1 FFC Domain Parameter Generation, I would rather that the g values selected in the correct cyclic subgroup. [4] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf > What would be the desired outcome of such a change to DH_GRP_MIN? To allow the paranoia the the current best practices be able to be set by the users of the client and the server. > Rendering it such that DH-GEX doesn't work for a given connection > makes it much more likely that the connection would use one of the > fixed groups, and group1 in particular seems at much higher risk for > LogJam style attacks than even a 1k group from a large and changing > set. You may be right, although I hope they do NOT choose diffie-hellman-group1-sha1 I would hope that they would be able to use one of * diffie-hellman-group14-sha1 * curve25519-sha256@xxxxxxxxxx * RFC 5656 ECDH curves (ecdh-sha2-nistp{256,384,521}) Longer term I favor * standard use of Curve25519 * standard use of Curve488 * standard use of Koblitz Curve K-233 (seems faster than the NISTP curves) * something the IRTF-CRSG suggests that can be standardized > [1] > https://anongit.mindrot.org/openssh.git/commit/?id=df62d71e64d29d1054e7a53d1a801075ef70335f > [2] > https://anongit.mindrot.org/openssh.git/commit/moduli?id=5ab7d5fa03ad55bc438fab45dfb3aeb30a3c237a Thank you, -- Mark _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
