openssh unix dev - Jul 2015 - DH_GRP_MIN is currently 1024, should it be bumped to 2048?

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?

If so, should this be just a compile-time change, or should there be a
new client and server runtime option?

	Thanks,
	-- Mark

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.

For b), we recently removed the 1k groups from the moduli file, so the
minimum that can be offered is 1.5 kbit.

What would be the desired outcome of such a change to DH_GRP_MIN?
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.

[1]
https://anongit.mindrot.org/openssh.git/commit/?id=df62d71e64d29d1054e7a53d1a801075ef70335f
[2]
https://anongit.mindrot.org/openssh.git/commit/moduli?id=5ab7d5fa03ad55bc438fab45dfb3aeb30a3c237a

-- 
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.

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