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

On Fri, 2019-02-15 at 15:57 +1100, Darren Tucker wrote:
> That was the original intent (and it's mentioned in RFC4419) however
> each moduli file we ship (70-80 instances of 6 sizes)  takes about 1
> cpu-month to generate on a lowish-power x86-64 machine.  Most of it
> is
> parallelizable, but even then it'd likely take a few hours to
> generate
> one of each size.  I imagine that'd cause some complaints about
> startup time.
One way of handling this, at least if the moduli generation was nicely
interruptable, is that distros ship a file, e.g. /etc/ssh/moduli.dist
but by some mean (init script, systemd unit, maybe even sshd itself) a
daemon that does calculation of new moduli values is started whenever
/etc/ssh/moduli (no ".dist") isn't found.

Since some systems (workstations, notebooks) may shutdown frequently,
this would need to be interruptable and resumable... e.g. on SIGINT/HUP
that calculation service would write to /var/lib/ssh/moduli.tmp or
whatever.


With new config options, distros/admin could even pre-set which and how
many groups are calculated.


Cheers,
Chris.

On 02/15/2019 06:07 PM, Christoph Anton Mitterer wrote:
> On Fri, 2019-02-15 at 15:57 +1100, Darren Tucker wrote:
>> That was the original intent (and it's mentioned in RFC4419)
however
>> each moduli file we ship (70-80 instances of 6 sizes)  takes about 1
>> cpu-month to generate on a lowish-power x86-64 machine.  Most of it
>> is parallelizable, but even then it'd likely take a few hours to
>> generate one of each size.  I imagine that'd cause some complaints
>> about startup time.
> 
> One way of handling this, at least if the moduli generation was nicely
> interruptable, is that distros ship a file, e.g. /etc/ssh/moduli.dist
> but by some mean (init script, systemd unit, maybe even sshd itself) a
> daemon that does calculation of new moduli values is started whenever
> /etc/ssh/moduli (no ".dist") isn't found.
I'm (manually) creating the shorter moduli anew for every VM I set up
(which may have but one core), but have the longer ones copied after
being created *once* for every "platform" (definition subject to
practicality). Running *that* much of ssh-keygen already takes longer
than people are willing to wait for the VM that's needed oh-so-urgently
for a customer-visible change. I can't say that I would be very happy
about an out-of-the-box "Hulk smash puny CPU!!" behavior.

Considering that the moduli file already varies with the distro, I'ld
say that the duty of recognizing it / that situation (and reacting to
it) is *not* on the OpenSSH maintainers, beyond maybe suggesting a
global mechanism to do so (*). Since /etc/ssh/moduli's syntax supports
comment lines, how about having the distro moduli files include one alike

# DO-MODULI-WARNING This is an unchanged $DISTRO moduli file. You *want*
to (create and) install one of your own (or delete this comment to hide
your disgrace and make this OpenSSH shut up).

and then have the distro's choice of escalating warnings /
countermeasures (**) triggered by a '^# DO-MODULI-WARNING' regexp?

(*) I first wanted to suggest recognizing distro's default moduli files
by checksum, but that would discourage having it updated / recomputed
frequently by the package maintainers (boatload of historic checksums to
check for), which is *not* what we want.

(**) Say, start with the equivalent of a hardcoded login banner,
escalate all the way up to running a *very* niced-down moduli generation
when nobody intervened for a year ...

Regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20190216/dd31d242/attachment-0001.p7s>

Or simply disable non-EC DH, like I do for all my servers.

On Sat, Feb 16, 2019 at 10:57 AM Jochen Bern <Jochen.Bern at binect.de>
wrote:
>
> On 02/15/2019 06:07 PM, Christoph Anton Mitterer wrote:
> > On Fri, 2019-02-15 at 15:57 +1100, Darren Tucker wrote:
> >> That was the original intent (and it's mentioned in RFC4419)
however
> >> each moduli file we ship (70-80 instances of 6 sizes)  takes about
1
> >> cpu-month to generate on a lowish-power x86-64 machine.  Most of
it
> >> is parallelizable, but even then it'd likely take a few hours
to
> >> generate one of each size.  I imagine that'd cause some
complaints
> >> about startup time.
> >
> > One way of handling this, at least if the moduli generation was nicely
> > interruptable, is that distros ship a file, e.g. /etc/ssh/moduli.dist
> > but by some mean (init script, systemd unit, maybe even sshd itself) a
> > daemon that does calculation of new moduli values is started whenever
> > /etc/ssh/moduli (no ".dist") isn't found.
>
> I'm (manually) creating the shorter moduli anew for every VM I set up
> (which may have but one core), but have the longer ones copied after
> being created *once* for every "platform" (definition subject to
> practicality). Running *that* much of ssh-keygen already takes longer
> than people are willing to wait for the VM that's needed oh-so-urgently
> for a customer-visible change. I can't say that I would be very happy
> about an out-of-the-box "Hulk smash puny CPU!!" behavior.
>
> Considering that the moduli file already varies with the distro, I'ld
> say that the duty of recognizing it / that situation (and reacting to
> it) is *not* on the OpenSSH maintainers, beyond maybe suggesting a
> global mechanism to do so (*). Since /etc/ssh/moduli's syntax supports
> comment lines, how about having the distro moduli files include one alike
>
> # DO-MODULI-WARNING This is an unchanged $DISTRO moduli file. You *want*
> to (create and) install one of your own (or delete this comment to hide
> your disgrace and make this OpenSSH shut up).
>
> and then have the distro's choice of escalating warnings /
> countermeasures (**) triggered by a '^# DO-MODULI-WARNING' regexp?
>
> (*) I first wanted to suggest recognizing distro's default moduli files
> by checksum, but that would discourage having it updated / recomputed
> frequently by the package maintainers (boatload of historic checksums to
> check for), which is *not* what we want.
>
> (**) Say, start with the equivalent of a hardcoded login banner,
> escalate all the way up to running a *very* niced-down moduli generation
> when nobody intervened for a year ...
>
> Regards,
> --
> Jochen Bern
> Systemingenieur
>
> www.binect.de
> www.facebook.de/binect
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev