On Wed, 10 Mar 2021, Mark D. Baushke wrote: > 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. I'm not sure whether that is a desirable thing to exploit to begin with - it's detectable (even off-path!) and a lot of work for an evil server to go through when they could just silently leak the derived key... > > 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. Yikes - ECC is faster and offers a far better security margin. group1 is probably going to be one of the next things we remove. > 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'm not sure what that means in the case of a PRF - no modern hash has (not even MD5) been broken so badly that it fails to function as a PRF. Unless you mean that the blocksize of the hash has to match the expected security level of the key exchange and/or that of the subsequent symmetric cipher. I'm not sure whether that is well- justified either - an interating hash-based KDF can have as many bits of output as you want, and SSH is almost always going to demand more bits from the KDF than the underlying hash block size (because 2x keys, 2x IVs, etc). > 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. I think the strongest argument for unconditionally deprcating SHA-1 everywhere is that doing so hastens the day when we can simply remove it. It's not great to leave partially-broken algorithms laying around and simpler for everyone just to get rid of them as fast as compatibility allows. > 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'm pretty much one of them :) I'm skeptical whether useful QCs will be a thing in my lifetime, but the probability is far enough above zero that it makes sense to use PQC if the costs aren't too high. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
