On Mon, 14 May 2018, The IESG wrote:
A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@xxxxxxxx) by 2018-05-23.
I have very mixed feelings on this. This area has been and will be dominated by big players who have a strong commercial interest at keeping their users seperated from everyone elses messaging system. A universal encryption message layer would not serve many people and would be trivial to block by the transport layer provider. In fact, that is why OTR (https://otr.cypherpunks.ca) was created. To create something that the uses existing message layers as a transport protocol. This allows an opensource chat client implementing multiple protocols to have one implementation of the message security subsystem and use that on top of any (proprietary) transport protocol. None of the listed goals on the proposed charter are unsolved problems, and by resolving these items again in another format won't improve the standarization.
Several widely-deployed applications have developed their own protocols to meet these needs. While these protocols are similar, no two are close enough to interoperate. As a result, each application vendor has had to maintain their own protocol stack and independently build trust in the quality of the protocol. The primary goal of this working group is to develop a standard messaging security protocol so that applications can share code, and so that there can be shared validation of the protocol (as there has been with TLS 1.3).
This assumes those vendors would actually want this. I strongly doubt that. Also, there are basically only two real protocols for this work currently deployed. OTRv3 and its derivative Signal. An OTRv4 (non-ietf) spec has recently been published for peer review. The Signal protocol has seen very wide adoption, yet it is completely run on isolated islands with zero federation and mandatory identity binding to a telephone number. I don't see this changing when the IETF tries to involve itself here.
It is not a goal of this group to enable interoperability/federation between messaging applications beyond the key establishment, authentication, and confidentiality services. Full interoperability would require alignment at many different layers beyond security
So it will not add much to the existing OTR or Signal protocols, and the real question is why don't we build on top of Signal or OTRv4? We have seen a number of efforts to block inline encryption. For example when you could still run XMPP with Facebook and you used an OTR plugin, Facebook would drop the messages preventing end-to-end encryption. Google also never tried to be more helpful when you used OTR over gtalk and had a gmail browser window open (thus had multiple identities online of which one could not speak OTR). Why would these players be nice to MLS? Furthermore, large deployments that used to be based on XMPP are moving from open to closed standards to prevent third party clients (and their end to end encryption plugins). They won't accomodate or even support MLS. Meanwhile, there is a protocol war between iMessage and Android/RCS. The result is that we have end to end encryption on one major phone vendor that refuses to interop with other vendors, and the other major vendor trying to punt this to the Telecom organisations which are all encumbered by Lawful Interception requirements. So RCS will never see end-to-end encryption. I don't think there will be much harm from the IETF pursuing this goal, but I don't think anything useful will come out of this either. If the IETF does want to try and standarize this space, I think it must really encode its message layer in a similar way to OTR, as the transports between users that run through third party servers will simply never allow passing any kind of binary data. However, such a goal comes dangerously close to intentionally subverting the transport layer in a way that the IETF normally does not engage in. Within all these constrains, what can MLS really over that OTRv4 or Signal does not offer already? And how will adding a third player improve this space? Did the IETF engage the Signal or OTR communities on how to consolidate this space into one protocol ? With these considerations, I am neither opposed nor in favour of this work being done at the IETF, with a slight preference of all of us instead working in areas where we can make a difference. Paul
