Re: [new-work] WG Review: Messaging Layer Security (mls)

[Paul Wouters <[e-mail]>]

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 ([e-mail]) 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