Algorithm negotiation really is necessary

[nicowilliams]

On issue #279 @keithw commented:

"[...]. I'm not really eager to make Mosh crypto-agile -- if you look at incumbent systems, like OpenSSH, cipher negotiation is a huge source of bugs and security holes. [...]"

Crypto-agility is necessary. Someday cryptanalysis of Mosh's crypto algorithms may show them to be substantially weaker than expected/desired and though it may not be immediately fatal to Mosh's security, such cryptanalysis may open the door to future cryptanalysis that does fully break Mosh.

The options available the day one of the algorithms used by Mosh begins to weaken significantly are:

• flag day switch to new algorithm

or

• switch to a new port number and use new algorithms there

The problem with flag days is that they are a terrible user experience. The problem with using a new port number is that port numbers are a scarce resource and worse: there will be a fallback to old number approach that is very likely to be susceptible to a downgrade attack!

The cryptanalysis of the now-weak algorithm might not be so devastating that only a flag day could address it. That is, it may be OK to continue to use the now-weak algorithm during the time it takes to migrate to a replacement algorithm.

The downgrade attack issue is where all the complexity is. You're clearly hoping to be able to avoid this complexity. I'm asserting from experience that you should not.

OpenSSH may be an example of complexity in algorithm negotiation, but it's also an example where algorithm negotiation has saved the protocol's bacon (think of the chained IV CBC cipher suites it used to use).

TLS is an example of a protocol where downgrade protection was not done well originally, an example of fallback reconnects.

My advice is to implement algorithm agility, that you get negotiation and downgrade protection right rather than avoid it out of fear of complexity.

[nicowilliams]

I should add that SSHv2's version negotiation and initial algorithm negotiation are done sufficiently well that a v3 will likely never be necessary. The one problem with SSHv2's negotiation is that it cannot be retried if it fails, which is a problem for GSSAPIKeyExchange, but hardly fatal.

We have had to make use of SSHv2's algorithm agility, so we know it works. And we know that its downgrade protection works and will work for as long as all of the algorithms offered by the client and server can provide integrity protection for the negotiation vis-a-vis any real-time attacks on those algorithms. A cryptanalytic break would have to be so complete that an attacker could mount a downgrade attack in real-time, but cryptanalytic breaks of standard algorithms for the past few decades have mostly been incremental rather than suddenly devastating.

[keithw]

Thanks for your input. We have the capability to support different ciphers if we want to; e.g. the client can specify its support with command-line options (out of band) when launching the mosh-server. This is how we would handle the eventuality you discuss. But I'm not eager to actually add a bunch of ciphers and agility until we have to. There's no reason to do it right now as far as I can tell -- but let me know if you can think of a reason otherwise.

I don't understand your message about switching to a new port number -- we don't have an assigned port number at all!

[nicowilliams]

The reason is testing. You want to know that the alg agility does work :) You don't need a real alternate cipher/mode, just a dummy one for testing will do -- just make sure that you don't actually install built objects with the dummy.

As for port numbers, I was referring to the port where the main server listens, like port 22.

[keithw]

We're pretty sure the server can read a command-line argument and respond to it. :-) (We are probably already going to need this mechanism for features like scrollback and port forwarding.) Re: port number, this is part of why we don't have a well-known port number or want one. The client only needs to learn the port number after he's executed the mosh-server, which can then print out whatever port number it wants.

Maybe in the future that will be the port number to a moshd multiplexer instead of the individual mosh-server, but it still doesn't need to be known to the client a priori.

[thorsimon]

As I noted in https://github.com/keithw/mosh/issues/359#issuecomment-11620199 unless you've obtained some kind of additional grant of rights under the OCB patent, you might really want this to work around the iOS licensing issues.

[keithw]

We don't have iOS licensing issues. We got the necessary rights a few months ago.

[uzytkownik]

Possibly a strange question (I'm not an security expert) - mosh handshake is through the encrypted and authenticated channel so if the negotiation would be through SSH what are the dangers of negotiation?

[nicowilliams]

Clearly mosh's security depends on SSH's. Algorithm agility for mosh adds no new security problems if the negotiation is done with the protection of ssh.

[achernya]

We can probably use the mosh startup banner to advertise supported cipher suites in a forwards- and backwards-compatible way.