License problem

[ghost]

GNU License not add your lib support :(

Coda = http://panic.com/coda/ iPad Coda = http://panic.com/dietcoda/

[kmcallister]

We know that GPL is problematic for some people. However, there are several reasons why changing Mosh's license would be difficult. One is that we use the OCB block cipher mode under a GPL-specific patent grant

There is much more discussion of this at #198. I'm closing this ticket as essentially a duplicate of that discussion.

[ghost]

maybe replace "OCB block cipher mode " to ECDHE keys ?? (openssl google edition)

Links: http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman http://en.wikipedia.org/wiki/Forward_secrecy http://cvs.openssl.org/fileview?f=openssl/CHANGES&v=1.1481.2.56.2.57

[kmcallister]

Sorry, I don't see how elliptic-curve Diffie-Hellman (a public-private key exchange protocol) is a replacement for OCB (a mode for symmetric block ciphers). Maybe you can elaborate. Right now Mosh has no public-key crypto at all, and we'd like to keep it that way, as it really simplifies the security story.

We use OCB because it provides authentication and encryption together as a single cryptographic primitive with a simple interface. There are alternatives such as GCM; @keithw chose OCB because it has a self-contained reference implementation we can bundle with Mosh. (I believe GCM was added to OpenSSL sometime around the release of Mosh 1.0, so it won't be available on most systems for many years.)

Or we could separately use CTR mode for encryption and a HMAC for authentication (as SSH usually does), but there are more ways to screw that up on our end. We might mix up the two keys, or fail to deal with variable length input to the HMAC. With a combined authenticated-encryption mode, there's less crypto-related code to write for Mosh, and that's a very good thing.

[nicowilliams]

Please use GCM, CCM, or any number of other cipher modes. Or use AES in counter mode, encrypt then MAC with a HMAC-SHA-something and truncate the HMAC to a suitable size (e.g., 96 bits, or 128-bits). It seems that SHA-256 and up perform much better than SHA-1, so pick one of those. Encrypt-then-MAC (and verify-MAC-then-decrypt) is the correct way to do AEAD by generic construction without shooting your feet off.

[kmcallister]

@nicowilliams: The whole point of using OCB (or GCM or CCM) is to avoid that complicated series of steps and design decisions. With a separate HMAC there are more ways for the application developer (us) to screw it up. We don't want to perform a generic construction for AEAD; we want to use someone else's ready-made AEAD primitive.

[nicowilliams]

@kmcallister: if you re-read my comment you'll note that my first choice would be a less-encumbered AEAD mode.

But as for screwing up generic composition: a) you're already using portions of SSHv2 anyways, so I'm skeptical of any such argument, and also of code complexity arguments, b) it's very hard to screw up encrypt-then-MAC/verify-MAC-then-decrypt -- there's no padding issues, for example. What's easy to screw up is in generic construction of AEAD modes is to forget to do encrypt-then-MAC and do the reverse, or to forget to verify the MAC before decrypting, both of which then leads to padding issues (unless you use a cipher mode that requires no padding, like, say, counter mode). If you had to go this route then choosing a padding-less cipher mode obviously reduces the scope for screwups, and in any case, we're all so aware of these issues that it's unlikely that we'd not notice them in design/code /spec reviews.

So, to repeat: please use a less encumbered AEAD cipher mode. If you should fail to find any suitable AEAD cipher mode then, and only then, fallback on generic construction.

The main problem with using encumbered algorithms is that you make it much. much harder to develop interoperable alternative implementations to Mosh, and harder also to eventually standardize the protocol. I'm imagining the OpenSSH crowd designing their own non-interoperable alternative with roughly the same advantages over plain SSH as Mosh (think of how screen(1) was not good enough for being GPLed, so the BSD crowd had to develop tmux(1). There's definitely value in having more than one implementation (see SSH, for example). (NOTE: I'm not threatening to fork the protocol or any such thing; I'm only afraid that that might happen, as I find it utterly predictable.) I think wider adoption and interop is much more valuable than any other value you might be getting from your current choice of encumbered algorithms. In particular I think it would be much better to have multiple interoperable implementations, or just one implementation of just one protocol, than multiple non-interoperable implementations of the same idea.

[nicowilliams]

Also, there's the whole iOS/GPL thing. Of course there the problem isn't Apple, but that you might have developers that refuse to let you distribute binaries for iOS (refuse to permit == creditably threaten to sue). (I'd argue that as long as the source is the same for iOS and other platforms then you're covered, but IANAL and all that. Also, it might be early enough in Mosh's development that you can manage the legal issues, and the fact that there's been talk of relicensing under MIT or BSD licenses would indicate as much to me. And if you've been requiring copyright assignment for contributions then there's no real issue.)

In fact, this might very well be what leads to a non-GPL implementation that also does not use OCB, a forking of the protocol!

[keithw]

We have waived the GPL-iOS conflict (see COPYING.iOS). 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. We picked OCB because it's the most deployable mode. The main problem with GCM or CCM is that they don't have implementations widely deployed or shippable. I think OpenSSL finally shipped a GCM implementation in 2012, after mosh 1.0 was released, but obviously it's not going to be available on most of the systems we run on.