Damien Miller <djm@xxxxxxxxxxx> 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
