Already, in the starting point draft, it's been crudded up: it has "ciphersuites", and comes with support for the NIST P-256 curve --- despite the fact that the underlying design wants to take byte strings to curve points, which is tricky to do on the P-curve. It will only get worse from here. They'll figure out some reason to bolt a PAKE onto it soon enough.
Signal Protocol is exceedingly well-documented (and even before those documents were written, it was open enough for Wire to lift the protocol wholesale).
The IETF is bad at cryptography. Your default position should be distrust of IETF crypto standards.
(I like my source on this, but can't share it; I expect to be able to this year, though. In the meantime:
0e49002152a374d9c11251cf856a7ccf25ef9bd0db54c3e97bef2a4109dad4f0)
2. Facebook's interests in the standard are not necessarily what drives the standard; Facebook can just be along for the ride.
I think what's going to happen with this is what happens to all de novo IETF designs other than TLS, the one that the market requires actually work: it's going to fail. That's also the outcome that I'm hoping for.
In the meantime, if Millican wants to get together with Katriel Cohn-Gordon and do a Facebook-only ART protocol design for Facebook Messenger, with an eye towards replacing Signal Protocol in WhatsApp, that would be a great development. So would a Cisco-only ART messenger, or maybe even a Mozilla ART messenger (though Mozilla's motives are the ones I trust least here).
What does not make sense is for a protocol whose service model we barely understand even in theory to be designed from scratch in an open standards group. The IETF motto used to be "loose consensus and working code". Now it's "take an RWC paper, add the P-curves to it, and use it to fuck over the most successful secure messaging protocol".
We shouldn't be cheerleading this. It's capture, not progress.
An open protocol is a prerequisite. There's a 2018 IETF proposal for interoperable E2E messaging, initiated by Cisco, Google, Facebook and Wire:
Architecture: https://datatracker.ietf.org/doc/draft-omara-mls-architectur...
Protocol: https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/?...
"Messaging Layer Security (MLS) ... is not intended as a full instant messaging protocol but rather is intended to be embedded in a concrete protocol such as XMPP [RFC3920]. In addition, it does not specify a complete wire encoding, but rather a set of abstract data structures which can then be mapped onto a variety of concrete encodings, such as TLS [I-D.ietf-tls-tls13], CBOR [RFC7049], and JSON [RFC7159]. Implementations which adopt compatible encodings should be able to have some degree of interoperability at the message level, though they may have incompatible identity/authentication infrastructures."