proposal: x/crypto/ssh: support Diffie-Hellman Group Exchange from RFC 4419

[nerdatmath]

A request for support of the diffie-hellman-group-exchange-sha1 key exchange algorithm was made on golang-nuts. This is supported by openssh 7.2 along with diffie-hellman-group-exchange-sha256, both of which are defined by RFC 4419.

[gopherbot]

CL https://golang.org/cl/29758 mentions this issue.

[quentinmit]

/cc @agl just to make sure there isn't a good reason we don't support these kex algorithms.

[baleksan]

Lack of support for diffie-hellman-group-exchange-sha256 is pretty limiting in our use-cases of SSH, and especially with compatibility of SFTP support over SSH.

[agl]

I've not looked at the linked CL, but the group-exchange protocol is SSH isn't great and goes against the direction that TLS is going. Technically it's probably ok, but it's mostly just excess complexity.

That's not to say that it's unthinkable, but it needs to be justified and there are so far only unsubstantiated requests here.

[hanwen]

it looks like this protocol needs an extra roundtrip to negotiate some parameter (the prime?). That makes it slow.

Is this because some SSH implementation stopped supporting the dh-group1 even though the SSH standards requires it? You'd expect a vendor that aggressively removed older algorithms to add newer algorithms (eg. ecdh-p256) to make up for that.

@baleksan - what does SFTP have to do with the key exchange algorithm?

[nerdatmath]

I would envision a case of competing requirements: an organization's internal policy may require they not use dh-group1 but for some other reason they are stuck using an older ssh implementation which doesn't support the latest algorithms but does support dh group exchange. That's just a guess though.

…

On Mon, Nov 28, 2016 at 10:10 AM Han-Wen Nienhuys ***@***.***> wrote: it looks like this protocol needs an extra roundtrip to negotiate some parameter (the prime?). That makes it slow. Is this because some SSH implementation stopped supporting the dh-group1 even though the SSH standards requires it? You'd expect a vendor that aggressively removed older algorithms to add newer algorithms (eg. ecdh-p256) to make up for that. @baleksan <https://github.com/baleksan> - what does SFTP have to do with the key exchange algorithm? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AClAHqROkV9aw2bt7oCFla9zvwypaurKks5rCxkagaJpZM4KF_jM> .

[breml]

TL;DR

There are real situations, where DH group key exchange is needed. We have a working solution for DH group exchange, where at least the client side is running in production. (Change to x/crypto/ssh, drop-in addion)
I realy would appreciate if DH group exchange would be added to x/crypto/ssh.

Background story

In our case, a large vendor of firewall appliances decided around a year ago to remove dh-group1 due to the security issues. On the other hand, they were not able/ready/willing to add new key exchange algorithms. This left us in a very unpleasant situation because our Go based tooling was no longer able to access these firewall via SSH. On the other hand, the vendor pointed out to OpenSSH and putty, as possible solutions to connect to the appliances. While this was a valid answer for manual tasks on these firewall appliances, it was still not a valid solution for us, because we lost our ability to automate tasks and to proper monitor these firewall appliances.

Implementation

My own implementations and the one provided in the CL by @nerdatmath are quite similar (ok, there is not much room for creativity).

I do offer to provide a new mergable CL.

Limitations

Both implementations currently lake a proper implementation to load additional moduli on the server side implementation. I did a first implementation but I would not consider it to be finished.

Alternative solution

Edited on 15.01.2017

The current way, how key exchange algorithms are registered forces users of x/crypto/ssh to fork the whole x/crypto repository to simply add an alternative key exchange algorithm. Maybe an interface could be provided, which would allow to provide an key exchange algorithm.

Remarks

Extra round trip

@hanwen mentioned, that there is an extra round trip involved for the key exchange. This is absolutely true, but is this a real argument against this algorithm? There are real world situations, like the mentioned situation above (removal of dh-group1 due to security reasons, without alternatives) where DH group exchange is the last possibility to still establish a SSH connection. In these situations as a user you are well willing to accept this additional round trip.

Unsustained requests

@agl mentioned in his comment, that currently there are only unsubstantiated requests. I would like to know, that would be needed, for this request to be enough sustained.
In my opinion, there is already some good justification in the following facts:

• DH group exchange is well defined in an widely accepted RFC
• Defacto standard implementations of SSH like OpenSSH (and putty on windows systems) do support this key exchange algorithm.

Addition resources

I would like to mention, that there existed already another requests to add DH group exchange to x/crypto/ssh:

• x/crypto/ssh: support curve25519-sha256@libssh.org and diffie-hellman-group-exchange-sha256 #11004

[hanwen]

The larger issue is that the SSH started out as a package that offered a sensible set of algorithms and secure defaults, but interoperability with ancient hardware and strange decisions by vendors (such as the one breml alludes to) are forcing us to add everything and the kitchen sink.

There a couple of ways out:

1. hold to the original ideal (and incommodate people like breml).
2. declare defeat, and host everything and the kitchensink in the SSH package. Downside: we have to vet all the implementations.
3. declare defeat, and make algorithms pluggable. Downside: extra API surface, more likely for poor crypto implementations to proliferate.

Adam?

I slightly favor 2), as there is a finite amount of historical cruft we have to add, but you're the crypto expert who would have to review the code.

[agl]

In two cases recently where I've added things to crypto/tls that were motivated by this sort of thing, I've regretted it. It's always going to be the case that those who would benefit from adding more cruft will advocate for it strongly, but the disperse costs will be ignored.

If we're going to add things, I think issues like #17676 have much greater merit since they're asking for things that are better designed than what we currently have.

[hanwen]

I guess we'll continue deciding this on a case-by-case basis then?

I think the decision of said vendor to remove dh-group1 but not provide dh-group14 (which is basically the same code but with a larger and therefore more secure prime) is silly, and the alternative kex qualifies as cruft, so I don't see why we would want to add it. File a bugreport with said vendor?

As a response to @breml : OpenSSH is actually actually removing older algorithms from their code base, see https://www.openssh.com/txt/release-7.0 - the fact that OpenSSH implements something by itself is not a proof that it's a good idea.

(if we were to take OpenSSH as a standard, we would be removing DSA support from the Go package.)

[davecheney]

I vote for option 1, hold the line. The are companies like active state who may be comfortable managing the risk of providing a fork of this package that includes deprecated algos.

…

On Tue, 17 Jan 2017, 03:56 Han-Wen Nienhuys ***@***.***> wrote: I guess we'll continue deciding this on a case-by-case basis then? I think the decision of said vendor to remove dh-group1 but not provide dh-group14 (which is basically the same code but with a larger and therefore more secure prime) is silly, and the alternative kex qualifies as cruft, so I don't see why we would want to add it. File a bugreport with said vendor? As a response to @breml <https://github.com/breml> : OpenSSH is actually actually removing older algorithms from their code base, see https://www.openssh.com/txt/release-7.0 - the fact that OpenSSH implements something by itself is not a proof that it's a good idea. (if we were to take OpenSSH as a standard, we would be removing DSA support from the Go package.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAzqzEAcqm0Eaw3dFid36QY-CgFe-ks5rS6FFgaJpZM4KF_jM> .

[breml]

@hanwen, @agl First of all I would like to thank you for looking at and commenting on this issue. I can assure you, that filling a bug with said firewall vendor was the first thing we did, even before we thought about implementing an additional kex for x/crypto/ssh. But as a "normal" customer (even with an installed base of several 100 devices) it is quite hard to get an open ear if you don't represent a Fortune 500 company (or something similar).

The solution I would hope for is that there is an API (proposal 3 by @hanwen), which allows to add missing algorithms. In fact this would also allow to test and use newer algorithms until they eventually become part of x/crypto.

I would like to know, how you define "cruft". As a non native English speaker, this translates for me to something like "unnecessary software". If this is an appropriate translation, this would lead me to the question, what is the definition of unnecessary. What would be for example the minimal required user base for a piece of x/crypto to not be considered unnecessary. In my opinion there are other parts within the Go ecosystem, which also only support a very small user base like exotic processor architectures and operating systems or not yet standardized network protocol proposals. Would this also be considered as cruft?

I can understand, if the decision is, that this kex is not integrated into x/crypto/ssh, because it is considered cruft. But in this case I would hope, that the same criteria would be applied to other parts of the Go ecosystem, as these parts also needed to be vet (as @hanwen puts it). Maybe there should even be some kind of guidelines, what requirements have to be fulfilled for a feature to be added. This is in my opinion especially true, if decisions are made on a case-by-case base.