MSC4153: Exclude non-cross-signed devices

[uhoreg]

Rendered

Conflict of Interest declaration: I am a member of the Spec Core Team, and am employed by Element. This MSC was written as part of my work on the Element Cryptography team.

[turt2live]

Implementation requirements:

• Client embodying these values (preferably cross platform).

[richvdh]

I believe that EW and EX both implement this, via their respective labs flags.

EW's setting looks like this:

[tulir]

Cross-signing in general is relatively easy to implement, but receiving messages from bridges may be a more complicated issue: most encryption-capable bridges (i.e. mautrix-*) only generate keys for the bridge bot, not every ghost, which means messages are sent with a different user than the user who created the megolm session.

We likely have to invent some new mechanism to "delegate" crypto to another user so that clients wouldn't get scared when ghosts send messages encrypted by the bridge bot. Generating keys for every ghost would be ridiculously wasteful, the bridge is a single entity so there's no reason for it to have more than one encryption device.

[uhoreg]

When you say "most encryption-capable bridges (i.e. mautrix-*) only generate keys ...", are you talking about device keys? Can you explain how megolm session distribution works with mautrix bridges? Is it something like: bridge generates megolm session, bridge bot sends megolm session to recipient, ghost sends encrypted message to room?

[tulir]

Yes, exactly

[tulir]

There was some discussion about this in #element-x-ios:matrix.org

For clarity: the wasteful part is not the device key generation itself, but rather the resulting large number of olm sessions when clients have to encrypt megolm sessions for each ghost individually.

Matthew suggested that the ghost could create a device with no identity key (to prevent olm sessions being created) and use it to sign the bot's device.

I'm thinking ghosts will probably need a cross-signing key (because that's the real root of trust). Maybe ghosts could just upload the bot's cross-signing key? They'd have the wrong user_id, which clients could detect to realize it's a ghost user. The key could also have a special usage field or something else as an extra ghost identification. Or maybe the user_id field should be the ghost, but there could be a new bridge_bot_id field which points at the bridge bot.

[tulir]

Oh, there's also another related annoying part: double puppeting, where bridge logs in with your account to bridge messages you send from the remote network using your real account instead of a ghost. Currently it works the same way as ghosts in terms of encryption: create megolm keys with bridge bot, send with double puppet.

The number of double puppets is generally much lower than the number of ghosts, so technically it would be fine to create a full e2ee session (which the user can then cross-sign normally). However, that would mean the bridge receives decryption keys for messages in all your rooms instead of only its own rooms, which is not great.

I don't think it's worth creating a separate mechanism for trusting double puppets, but at least the "upload bot's cross-signing keys to ghost" mechanism wouldn't work for double puppets. Creating a device without identity keys could work for both though

[uhoreg]

I think that it's a bug that we're accepting messages encrypted using a key that we received from a different user, because that seems bad from a cryptographic point of view. So I'm not too keen to try to work around it. I also don't think that we should have bots upload cross-signing keys of different users.

If the big issue is in receiving encrypted messages, maybe the easier solution would be to add a flag in the device keys object to indicate that the device doesn't want to receive any keys?

[tulir]

The flag to not receive encrypted messages sounds good, that'd at least solve the double puppeting issue of receiving unwanted keys. Sending messages would still require creating olm sessions from every ghost that sends messages though

Technically there's also the option of deciding that appservices were a mistake and switching to MSC4144, but having to build duplicates of a bunch of different mechanisms like member lists and membership actions would be unfortunate

[uhoreg]

I've written MSC4261 to propose adding a flag to mark devices that don't want to receive room keys.

[TheArcaneBrony]

If a client enforces cross signing, how would cross signing work without access to other devices or recovery key?

Real scenario that happens to me from time to time:
Not all my accounts have the same powerlevel in rooms, sometimes I need to switch accounts on the go to carry out a moderation action. Worse, most of the moderation bot rooms I interact with on the regular use End-to-End Encryption (usually via Pantalaimon). Additionally, I do not feel comfortable keeping a copy of my Recovery Keys on my phone, or accessible to my phone, nor want to rely on physical devices (eg. security keys) when eg. going to a party, hanging out with friends at an entertainment park, etc.

Element X Android provides a good example here: while I enjoy using sliding sync, using Element X left me unable to carry out moderation actions due to being unable to switch accounts without cross-signing.
I'm currently using Schildichat Next to bypass cross signing requirements, but having multiple copies installed would exacerbate my out-of-memory issues on my phone, which are already preventing me from using it effectively at all.

[dkasak]

The paragraph says "may even", so enforcing cross-signing when logging in is not a requirement. Moreover, moderation actions are usually state events, which are not E2EE authenticated at the moment, so the situation there should remain unchanged.

Your unsigned device should get ignored for everything that is E2EE authenticated though, and for a good reason—the very concept of unsigned devices is unsound in an E2EE setting, because such devices can be freely added by the server, so in what sense is it E2EE at all? I don't think your scenario has much bearing on that fact.

[FSG-Cat]

The reason why moderation bots is a concern is because they are controlled via regular messages in dedicated rooms. Said room if your using mjolnir is recomended to be Encrypted.

[uhoreg]

Moving morguldir's comment here, to discuss whether we should use m.unverified for this, or use a new code:

I think it would make sense to use a m.room_key.withheld code here, tulir proposed a new code m.not_cross_signed

Adding this would make it easier to separate unverified users and insecure devices, like mentioned in element-hq/element-meta#2621

[richvdh]

Moving @escix 's question to a thread:

I am a non-technical person, so apologies if I am not making sense in my comments.

Currently, EX uses three identity confirmation methods:

• Use another device= This is the easiest one as all cryptography is already done in another device.

• Enter a recovery key= This, I believe, is the Security key to obtain the encryption key from the server.

• Can't confirm= This is to reset my message history and setup a new Security key.

If I understand properly, this MSC is to make login, identity verification and backup on the first login simple and efficient.

Login: dealt with username and password

Identity verification: Unless the persons are next to each other this will be an out-of-band confirmation. If the persons are next to each other this can be verified by scanning a QR code or something. On an out of bound scenario, this can be a phone call and confirmation of emojis or random numbers. However, in the current proposal, in the first use it is proposed to accept the identity by default. This will improve the user engagement, but can an advance section present so the above methods can be used by advanced users?

Backup Security keys: I think, by default, the encryption keys must be saved in the server and also in the device (downloaded as a file). Both can be protected with the same Security key.

So on the first login, use the username and password to login and presented with the option for identity verification with a skip button for non-technical users. Then proceed to 'backup encryption keys' with a Security Key.

[richvdh]

Your questions aren't easy to understand, but:

However, in the current proposal, in the first use it is proposed to accept the identity by default. This will improve the user engagement, but can an advance section present so the above methods can be used by advanced users?

Yes, it is proposed that users will trust other users' identity on first use, but it will still be possible to verify other users' identity explicitly via QR codes or emoji. And some applications may expose a feature where they will only send messages in rooms where all users have been explicitly verified in this way. I don't think there are any plans to support that in EX, but that would be a matter for the Element X issue trackers, not this Matrix spec proposal.

Backup Security keys: I think, by default, the encryption keys must be saved in the server and also in the device (downloaded as a file). Both can be protected with the same Security key.

I think that when you say "Backup Security keys", you mean what we now refer to as the Recovery key? (see also element-hq/element-meta#2394 (comment)). I don't think this MSC changes anything in this area.