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).

[deepbluev7]

I don't see how that name has anything to do with the proposal? Maybe the MSC could explain, where that name comes from?

[richvdh]

The name comes from the fact that crypto should "just work", rather than continually bothering users with popups or warnings or multi-coloured shields which they need to understand. In other words, it should be "invisible" to the casual user.

But yes, that could do with writing in the MSC.

[richvdh]

It might be better to rename this MSC to more closely represent the changes ("isolation of unsigned devices" or something); this MSC is really just a small part of "invisible crypto"

[uhoreg]

After discussion with the rest of the Element crypto team, we came to the consensus that "Invisible crypto" referred more to specific UI changes that this MSC would enable (such as getting rid of some shields), rather than the recommendations in this MSC. So I've given this MSC a more boring name. The filename will remain the same, so that we don't lose comments.

[richvdh]

don't these two paragraphs say the same thing? Or am I missing a subtlety?

[uhoreg]

The first is referring to this paragraph in https://spec.matrix.org/unstable/client-server-api/#key-storage:

A key can be marked as the “default” key by setting the user’s account data with event type m.secret_storage.default_key to an object that has the ID of the key as its key property. The default key will be used to encrypt all secrets that the user would expect to be available on all their clients. Unless the user specifies otherwise, clients will try to use the default key to decrypt secrets.

and is saying that the user's Secret Storage should have such a key.

Whereas the second paragraph is describing what secrets should be stored.

Perhaps it would make more sense if I switched the order of the paragraphs, since the first paragraph also touches on what's stored.

[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

[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.

[bnjbvr]

typo:

Suggested change

	may be allow the user to override this behaviour for specific devices for
	may allow the user to override this behaviour for specific devices for

[FSG-Cat]

This MSC has some severe T&S related security problems by effectively acting as a availability break. Now once the bot ecosystem has advanced sufficiently in its E2EE implementations this problem can be resolved. Recovery Keys will allow easy self restoration of cross signed status just like we have access to today in normal clients like Element Web.

Thanks to Tulir in the Spec room for mentioning Recovery Key based workflows as a realistic way to help resolve this conflict.

[MTRNord]

It also would be nice to point the potential tripwires for headless clients in the spec text later on as an info box. Since this is a thing easily overlooked imho if you aren't proficient in e2ee.