openssh unix dev - Feb 2019 - Can we disable diffie-hellman-group-exchange-sha1 by default?

Also, how are default moduli shipped with OpenSSH for use in
diffie-hellman-group-exchange-sha1/sha256 chosen? Are they chosen
randomly by developers or are they chosen for security properties? If
they are random, why not use moduli from RFC 7919 instead, like
Mozilla recommends?

On Fri, Feb 15, 2019 at 3:48 AM Mark D. Baushke <mdb at juniper.net>
wrote:
>
> Yegor Ievlev <koops1997 at gmail.com> writes:
>
> > Can we disable diffie-hellman-group14-sha1 too?
>
> It is possible to disable the diffie-hellman-group14-sha1 key exchange,
> but I personally recommend you just put it at the end of the list, so it
> is not normally used for the key exhcange unless that is the ONLY thing
> that your client has in common with the server (or vice versa).
>
> I know of a number of devices out there which want one of the MTI key
> exchange methods to be used.
>
>         -- Mark

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

On Fri, 15 Feb 2019 at 13:21, Yegor Ievlev <koops1997 at gmail.com>
wrote:
> Also, how are default moduli shipped with OpenSSH for use in
> diffie-hellman-group-exchange-sha1/sha256 chosen? Are they chosen
> randomly by developers or are they chosen for security properties?
A bit of both.  They're generated using ssh-keygen(1) in a 2 step
process (look for the -G and -T options).  For each group size,
candidates are picked at random and then screened (see
https://github.com/openssh/openssh-portable/blob/master/moduli.c).
> If they are random, why not use moduli from RFC 7919 instead, like
> Mozilla recommends?
Quoting RFC4419 (which predates 7919 by more than a decade):
"""
   we fear that extensive precomputation and more efficient
   algorithms to compute the discrete logarithm over a fixed group might
   pose a security threat to the SSH protocol.
   The ability to propose new groups will reduce the incentive to use
   precomputation for more efficient calculation of the discrete
   logarithm.  The server can constantly compute new groups in the
   background.
""

Using a small, fixed set of groups shared with another protocol would
be counter to this goal (see also: LogJam and the Oakley groups).
You're welcome to replace your file with the ones from RFC7919,
though.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

I'm not nearly knowledgeable enough in crypto to fully understand your
answer, but I will try. I wonder why moduli are not automatically
generated the first time sshd is started though. That would make much
more sense than shipping a default moduli file but also asking
everyone to replace it with their own.

On Fri, Feb 15, 2019 at 5:50 AM Mark D. Baushke <mdb at juniper.net>
wrote:
>
> 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

The main concern about this method is that such file is not
independently reproducible. This may be worrying for some more
paranoid folks.

On Fri, Feb 15, 2019 at 6:04 AM Darren Tucker <dtucker at dtucker.net>
wrote:
>
> On Fri, 15 Feb 2019 at 13:21, Yegor Ievlev <koops1997 at gmail.com>
wrote:
> > Also, how are default moduli shipped with OpenSSH for use in
> > diffie-hellman-group-exchange-sha1/sha256 chosen? Are they chosen
> > randomly by developers or are they chosen for security properties?
>
> A bit of both.  They're generated using ssh-keygen(1) in a 2 step
> process (look for the -G and -T options).  For each group size,
> candidates are picked at random and then screened (see
> https://github.com/openssh/openssh-portable/blob/master/moduli.c).
>
> > If they are random, why not use moduli from RFC 7919 instead, like
> > Mozilla recommends?
>
> Quoting RFC4419 (which predates 7919 by more than a decade):
> """
>    we fear that extensive precomputation and more efficient
>    algorithms to compute the discrete logarithm over a fixed group might
>    pose a security threat to the SSH protocol.
>    The ability to propose new groups will reduce the incentive to use
>    precomputation for more efficient calculation of the discrete
>    logarithm.  The server can constantly compute new groups in the
>    background.
> ""
>
> Using a small, fixed set of groups shared with another protocol would
> be counter to this goal (see also: LogJam and the Oakley groups).
> You're welcome to replace your file with the ones from RFC7919,
> though.
>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.