End to End Encryption SIG - 2022-11-10

I hate to say this in the middle of the TWOMEMO roll-out, but... anyone interested in MLS?

MattJ: what is any of that

End-to-end encryption

https://datatracker.ietf.org/wg/mls/about/

Is MLS actually being deployed anywhere? I thought it was still in its infancy

It's not yet deployed, no. But it's at the stage where an Implementation of the Transport layer using XMPP could start to be defined & implemented

MSavoritias (fae,ve), a beta roll-out for at least one (open-source) product is expected very soon. I don't know if that's public information, but here's an interesting repo I found: https://github.com/wireapp/core-crypto ;)

It's still in its infancy, but it's starting to take its first steps

Maybe they'll be wobbly steps, but now is a good time to figure out if/how we can/want to map this to XMPP

MLS is basically a hard requirement for MIMI at this point, which is why I'm bringing it up right now

Yeah i saw in the meeting. Its built on top

I think its all up to: Will we have gateways that support e2e encryption in MLS

Because that seems like the whole point of it imo

Gatekeepers you mean?

Nobody can predict, and they haven't said anything officially so far, but there are indications that they're at least interested

But even if we don't do it for MIMI, there may be other reasons

It's more scalable than OMEMO, and has some nice security/privacy features, such as cryptographically-assured group membership (the lack of which bit Matrix hard, if you saw their recent security flaws announced)

We barely even try to have that now, with OMEMO. Just a confirmation screen in Conversations that people complain about :)

If we do certain things in certain ways, we can also go some way towards hiding group membership from the group service itself

Also, Matrix may never get MLS, as it's not very suited to the eventual consistency model it uses. That might be something interesting to further differentiate the two protocols.

and if they do, who knows, we might get a decent bridge thanks to MIMI

So you are thinking of using mls for group encryption since its basically unarealistic in omemo? I could see that being very desirable

> MattJ: > Gatekeepers you mean? I meant generally gateways. Like to wire, signal and the likes. So we van send messages encrypted over the bridge

Traditional gateways can't support E2EE, because it prevents them from performing the necessary translation between the protocols

Unless you consider the gateway one of the E's

Which most people obviously don't want to do

With MIMI+MLS that may change

Yeah that was my thinking

There is more chance of other platforms adopting MLS than adopting OMEMO

I agree. That is why i was saying the whole value proposition of MLS would be if it gets adopted in other services and we can do e2e over the gateway with MIM.

So I think there are many interesting reasons we should be looking at MLS in XMPP, even if MIMI doesn't succeed

Now if its also better for groups than omemo then i would say its definetily worth it to have it. Since the group encryption in xmpp is pretty much broken with omemo

Agreed

It's much better for groups, and designed to scale much better than the existing solutions

We have challenges though, such as... can we use it in 1:1? do we want to?

Some platforms model 1:1 as a 2-person group, but XMPP does not

It makes a difference. In MLS the group service enforces some rules, such as ensuring everyone gets a consistent ordering of events.

In 1:1, there is no such authority over the communication, each user's server is simply a peer to the other

I heard some interesting solutions to that, such as making two fake groups, one on each server, and keeping two separate (but equivalent) states.

Seems complicated though, so we might want to just start with using it for groups

Yeah i think replacinp everything with it is unrealistic right now. But for groups i think everybody will agree its a better solution than omemo. Except OX people

Personally i think its to XMPP benefit that we seperate 1:1 and groups. Because we can havn different properties for each.

Could be just me though

Yeah, I generally prefer our model

It has pros and cons, but I like that it is simple and intuitive to send a message from A to B

I remember matrix having issues with everything being room also

Yeah

Yes, such as two people potentially having multiple rooms between them

Gets complicated to hide such situations from users, who think they are just messaging each other directly

Yeah. They had to implement them as 1:1 persistent rooms or something

Compared to oldmemo and twomemo, where does MLS fit regarding “full stanza encryption”?

If the thing we encrypt is an XMPP stanza, I highly doubt other protocols will be able to interoperate with us.

But if we go the oldmemo way and encrypt only the body of a message, it’s going to be the same bad thing where we have to disable every single advanced feature of XMPP.

I mean E2EE gateways isn't the goal of MLS. Just because you all use TLS doesn't imply your protocols are compatible all of a sudden, does it? The primary idea was to develop a proper, well-designed specification that is specified in a way that makes it very easy for libraries to be absolutely agnostic of the actual protocol, just like TLS is designed to not need to care about the protocol it protects, or the transport layer technology. MLS will improve the security of chat by providing developers with high-quality cryptographic libraries they can use, just like OpenSSL et.al. improved the state of the art in transport layer encryption.

If Matrix and XMPP were both to use MLS, I could imagine a gateway transporting encrypted JSON / XML payloads and clients on both sides actually understanding both. Adding a second translation to internal data structure is probably not too hard. Maybe not all features will be supported, but at least some can be done. Of course it would be even better if we could build a common standard for the encrypted payload. A standard with a democratically-elected committee deciding on what is accepted, with various optional extensions, ... - something like XMPP and very much unlike Matrix, so it's not going to happen

Yeah.. But then again i dont think gateways can guarantee much more than text. And judging by the other gateways matrix developed it doesnt even look desirable

The soft requirement of having a shared payload format is what makes MLS uninteresting for me (yet).

I think once the MIMI group settles on a shared format, MLS gets really interesting

Does anyone know what the library ecosystem for MLS is looking like?

vanitasvitae, I have been told that there are two main active implementations, both in Rust

One is https://github.com/wireapp/openmls - the other is by Cisco I think, but I'm not sure of the name

I see

The response to the several comments about MLS being uninteresting while the encrypted payloads are incompatible: defining a standard format for the encrypted payloads is one of the goals of MIMI

Otherwise, yes, MLS alone doesn't magically get you the interop

So basically MIMI is what larma said. Nobody knows what the "content format" (is what they're calling it) will look like yet, but I've no doubt everyone involved has an opinion that will be shared in the coming months

I'm also of the opinion that if we want this interop (assuming MIMI gets picked up by others) then yeah, XMPP clients will need to support this content format and I'd like to think it wouldn't be too hard (I doubt they're going to use XMPP XML, but you never know)

I think any attempt to standardize the content format is doomed to fail. You can probably get consensus to have something like a JSON with a field `type` that can be `message` and a field `body`, and agree that this should include an unformatted text representation of the message's body and then vendors can add any additional fields or types - but everything beyond that I've serious doubt it would be widely accepted and even that is unlikely. Different messengers have different UX expectations and thereby different protocol requirements, even when we're only talking about the messages itself.

I mean we already struggle to find a common standard for message formatting within XMPP (XHTML-IM, Styling, Markup, ...)

Yep. But it's not impossible to imagine that *something* gets standardized. Not saying it will be something great :)

And we'll be back to the same old thing: UX of bridged chats < UX of native chats

> high-quality cryptographic libraries they can use, just like OpenSSL Strange, a shiver just went down my spine