proposal: x/crypto/ssh: support server-side Diffie-Hellman Group Exchange

[alextadams88]

Support for Diffie-Hellman Group Exchange was proposed and added in the linked proposal: #17230

This was marked as closed and completed.

However, the PR that actually closed and completed this only implemented client-side kex. It did not implement server-side; only a minimal implementation to allow tests for the client-side to pass. See PR https://go-review.googlesource.com/c/crypto/+/174257 and commit golang/crypto@57b3e21.

I posit that the original issue should not have been marked as closed and completed because it was not truly completed as the Diffie-Hellman Group Exchange is still not fully supported.

[seankhliao]

cc @golang/security

[FiloSottile]

Server-side support was intentionally left out. Diffie-Hellman Group Exchange is complex, and I wish we could have implemented none of it. People argued that it was necessary to connect to certain servers, so in the name of compatibility we added client-side support. What's the argument for adding server-side support?

[alextadams88]

The original discussion thread did not contain a justification or discussion as to why server-side shouldn't be supported, so it appeared to me to be somewhat of an oversight as the discussion implied that this kex algorithm was fully supported, when it is not. That's why I created this proposal, just to make sure the team was aware that it was not fully supported.

As far as an argument, I can't provide anything except for information about my use-case, which doesn't really answer your question, but I'll provide the info regardless.

We have written an SFTP server using golang that allows our various downstream applications to SFTP backups to the server. It needs to do additional post-processing and forwarding to the backups, hence why we aren't just using OpenSSH on a filesystem. One of these applications supports only diffie-hellman-group-exchange-sha256, so as a result we cannot accept backups from that system. Because golang does not support this, we are looking into other solutions specifically for that application.

I suppose if I had an argument, it would simply be that this makes golang a poor choice for writing any kind of SSH server, if it means that arbitrary clients using non-deprecated algorithms will be unable to connect. In the future, it will make our team re-think using golang when solving problems like this.