DH_GRP_MIN is currently 1024, should it be bumped to 2048?

[Mark D. Baushke]

Hi Darren,

Many thanks for your response.

Darren Tucker <dtucker at zip.com.au> writes:

> On Sat, Jul 25, 2015 at 9:25 AM, Mark D. Baushke <mdb at juniper.net> 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 at libssh.org
    * 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