It's easy to shoot yourself in the foot with TLS (see: OpenSSL). Also, TLS has roots in a time where we knew much less in terms of crypto; as time went on and flaws were discovered, SSL/TLS was patched all around, meaning it has become much harder to implement correctly.

Noise starts from a clean state with modern knowledge of cryptography and modern cryptography. Much easier to understand and replicate, much harder to shoot yourself in the foot with.

TLS brings modularity and evolutivity, much needed in a protocol the scale of HTTP. In Whatsapp's case, Whatsapp controls both the server and the client; it is much easier to transition between versions because all bricks are under control. When you don't need what TLS brings anymore it makes sense to discard it.

As another example: Tarsnap (https://www.tarsnap.com/) uses spiped (https://www.tarsnap.com/spiped.html), a very simple yet powerful mechanism to build an encrypted channel. Its protocol and proof fit in ~100 lines (https://github.com/Tarsnap/spiped/blob/master/README). When you don't need all the jazz provided by TLS (and when you're lucky enough to be able to pre-share keys, which helps a lot) then a simple protocol is good.

It looks like Noise leaves an implementer with more than enough rope to hang themselves with - for example, it allows unauthenticated Diffie-Hellman, it appears to permit user-selected handshake sequences, has 16(!) different official handshake sequences with subtly different properties, each of which allow payloads to be attached to any message in the handshake process that in turn have different levels of reduced security, etc.

You're describing Noise. WhatsApp uses Noise Pipes, which is one of many instances of the Noise framework.

You're right that it's not a good idea for generalists to pick up Noise and go to town with it. Noise isn't misuse-proof.

> You're right that it's not a good idea for generalists to pick up Noise and go to town with it. Noise isn't misuse-proof.

Nor is SSL. Couldn't an opinionated SSL library (supporting exactly one protocol version, one cipher only, etc) provide the same simplicity of use while remaining interoperable and reusing an already-validated protocol?

Simplicity of use isn't the only benefit they get from Noise Pipes; they also get increased security, in a couple of important ways.

It's not the choice I would have made, but I am not as good as Moxie or Trevor.

FYI there is an RFC (currently a draft) for a suite of parameters considered secure for some time, ie some kind of LTS: https://tools.ietf.org/html/draft-gutmann-tls-lts-02

The idea is more or less what you want, hardcode some known-good configuration for servers that can't or won't be upgraded every other month.

That appears to not fully interoperate with regular TLS implementations, and does not require the use of the most popular secure ciphersuite ECDHE_RSA_AESGCM. If they need to make changes to make it secure, define an extension and say this profile makes the extension mandatory (like MAC-then-encrypt), but don't just change the protocol.

This is less a practical draft and more a political statement about the author's dislike for TLS 1.3. In particular, it makes extensive modifications to the TLS protocol itself (it doesn't merely propose a limited set of safe parameters).

> It's easy to shoot yourself in the foot with TLS

I would argue it's easier to shoot yourself in the face trying to re-implement/re-design something like TLS.

The mind behind Noise (Trevor Perrin) is one of the minds behind Axolotl (actually Noise can be seen as a generalization of the Axolotl's cross-signing of DH keys, see this post: https://whispersystems.org/blog/simplifying-otr-deniability/) so I would likely be comfortable with it. Although it is completely true that it's been far less used and studied than TLS.

The OP's point is that it is like TLS, except with a novelty effect. Personally, I prefer that everyone standardize than use a hundred different crypto protocols, none of which receives adequate scrutiny. TLS1.3, with encrypt-then-MAC and zero-RTT setup, can't get here fast enough.

About 6 round trips, which gives you about a 30s latency on EDGE networks. Doing a key exchange once, retaining it and then doing future communications with just 1 round trip is significantly faster.

Isn't a full TLS handshake 6 messages (thus 3 round trips)? Also with false start and resumption, TLS can also typically achieve 1 roundtrip, right? (I'm also confused by 30s latency for 6 RTT, but maybe I"m too focused on US market, where EDGE latency would be more like 500ms each way.)

Maybe not all of WhatsApp's platforms support the latest TLS improvements though, thus it's easier to roll their own?

I'm curious about this too. Short of some rigid technical requirement, it's hard to imagine why you'd want to reinvent the wheel or forgo a protocl which is so widely available and studied. (Although I've not read the Noise whitepaper though, I'm sure it must have some benefits compared to TLS.)