Can we disable diffie-hellman-group-exchange-sha1 by default?

[Mark D. Baushke]

Yegor Ievlev <koops1997 at gmail.com> writes:

> Also, how are default moduli shipped with OpenSSH for use in
> diffie-hellman-group-exchange-sha1/sha256 chosen?

You should never use a moduli file shipped by any distribution. Ever.

If you are using OpenSSH, then look at the moduli command to generate
the moduli file.

That said, you may generate P and Q any way you like, the goal is that
they be safe primes with a small generator G.

Although, if you follow the suggestions in RFC4419, you will more than
likely select a safe-prime G,Q,P set where the generator g will not
generate a proper Q-Ordered subgroup of P. This is a big deal if you
want to do FIPS certification. That said, NIST still has not come out
with a change to their standards to allow safe-primes in the general
case for Diffie-Hellman key exchange, so FIPS certification folks will
normally need to avoid configuring
diffie-hellman-group-exchange-sha1/sha256 in any case.

> Are they chosen randomly by developers

The should be generated randomly at an appropriate distributions of
sizes.

> or are they chosen for security properties?

That they are not fixed moduli is the security property itself.

> If they are random, why not use moduli from RFC 7919 instead, like
> Mozilla recommends?

Ahh... a philosophical debate? The selection of primes generated
based on digits of PI (RFC3526) vs E (RFC7919) (Euler's Number)?

https://www.pleacher.com/mp/mhumor/epi.html
https://www.reddit.com/r/math/comments/na7ua/pi_vs_e_debate/
https://math.unca.edu/sites/default/files/documents/2013ParsonsLecture.pdf
https://www.maa.org/press/maa-reviews/the-great-pie-debate

If you like using fixed moduli, then you may wish to look at RFC8268.
Of the proposed additions, OpenSSH provides these:
  diffie-hellman-group14-sha256
  diffie-hellman-group16-sha512
  diffie-hellman-group18-sha512

The purpose of the RFC4419 moduli is that it is desirable that a state
actor is not able to pre-generate the list of all possible
public/private values on the RFC3526 or RFC7919 published primes.

By generating a large set of primes for your own server, you make it a
lot harder for anyone to be able to eavesdrop on your conversation.

Using a very large subgroup such as is provided by safe-primes means
that the number of public values sent over the wire will also be very
large.

Selection of an improper generator means that that there may be more
than one solution for the public X that is passed. Generally, it is
considered that this will reduce the size of the effective security of
the prime moduli by one bit. So, a G,P where P is 2048 bits may find
that if G^X mod P does not generate a Q-ordered subgroup, the security
of the exchange may only be 2047 bits. The way to validate this is to
use G^Q mod P and if the value is 1, then G is a proper Q-ordered
subgroup.

The alternative to using RFC4419 would be to generate a provable primes,
but then you have the issue of selection of Q and G properly and the
client would not necessarily know the value Q being used as it is not
sent by the RFC4419 protocol as it is assumed Q may be calculated by the
client if they need it.

I hope this answers your question.

	-- Mark