Damien Miller <djm at mindrot.org> writes:
> On Wed, 10 Mar 2021, James Ralston wrote:
>
> > As others have mentioned, there is guidance about this in
> > draft-ietf-curdle-ssh-kex-sha2:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
> >
> > In summary, of these SHA-1 KexAlgorithms:
> >
> > * diffie-hellman-group1-sha1
> > * diffie-hellman-group14-sha1
> > * diffie-hellman-group-exchange-sha1
>
> (none of these are enabled by default in OpenSSH)
I agree.
> > and these SHA-1 GSSAPIKexAlgorithms:
> >
> > * gss-gex-sha1-
> > * gss-group1-sha1-
> > * gss-group14-sha1-
>
> (these are added by a popular third-party patch to OpenSSH)
Yup.
> > ?if it is necessary to enable one of them for backward compatibility
> > with clients/servers that support only SHA-1 algorithms, then this is
> > the only one that should be enabled:
> >
> > * diffie-hellman-group14-sha1 (for KexAlgorithms)
> > * gss-group14-sha1- (for GSSAPIKexAlgorithms)
>
> Disagree. diffie-hellman-group-exchange-sha1 will use a bigger/better
> MODP group than group14. If I had to enable one then that would be it.
It is hard to know what a particular server is going to put into that
file. It may or may not be the moduli file shipped with OpenSSH. The
OpenSSH 8.5p1 release seems to provide many 2048-bit MODP groups.
It can also be hard to know if a third-party is injecting a PseudoPrime
there... I have an idea for 'fixing' that, but I have not written an
IETF Draft to do anything about it, nor have I provided patches to
anyone for it.
> As an aside, I don't think there is honestly any concern about using
> SHA1 in the key exchange hash - collisions there don't matter as the
> hash is used solely as a PRF and the input to hashing is not under
> either party's sole control.
Yup, that is a completely rational point of view.
There are those out there with IoT devices that need/want to continue
using diffie-hellman-group1-sha1 key exchanges.
There are those out there (mostly banks and governments) who are more
paranoid about SHA-1 being broken "very soon" as well as those who are
pushing for calculations on security level (bits of security) being
maintained throughout the calculations.
I started out wanting to get an RFC to disallow
diffie-hellman-group1-sha1 and rsa1024-sha1 key exchanges and the
requirements for my draft kept growing until now it is almost trying to
be a best practices document.
Removing all of the *sha1* hashing in key exchanges is desired by some
and transitioning from a MUST (for the original group1-sha1 and
group14-sha1 kex list) implement to SHOULD NOT or MUST NOT implement for
others.
There are those who feel that FFC should be thrown away in favor of ECC
key exchanges and those who file that PQC is coming soon and will be
able to factor ECC faster than FCC.
I am presently trying to make the argument that *sha1* in the key
exchange is not as good as *sha256* or *sha512* or (for ecdh-nistp384)
sha384.
In my opinion, if you need a *sha1* kex in your list, then put it at the
end of the negotiation list. In the best of all possible worlds, they
should not really be needed. However, we are not there given an
installed base of SSH implementations exist for some devices that still
want to use group1-sha1 only.
Be safe, stay healthy,
-- Mark