Allow saying "I am OK with user A impersonating me"

[andybalaam]

As described in https://github.com/element-hq/element-meta/issues/2950, some bridges create "ghost" users, who do not have cryptographic devices, and send messages from the bridge's device, "faking" the sender.

In #2950 we propose to allow this behaviour but make it clearly visible in the UI.

In this issue we propose to restrict this behaviour, so it is only possible if the ghost user explicitly publishes something saying "I am OK with user A impersonating me". Then clients can hide messages that fake senders if the sender in question has not published this thing.

Note: the solution should also work for "double-puppeted" users i.e. users who do have real devices, but have also given a bridge permission to speak on their behalf.

Design a cryptographically-secure mechanism of publishing this information ("I am OK with user A impersonating me").

Write an MSC proposing this mechanism.

Implement it in Element clients.

[uhoreg]

One possibility is to create a special device to hold this information, which could have the MSC4261 do-not-encrypt flag. For double-puppeted users, this device would be controlled by the AppService.

Another possibility is to put this information in the user's MSK, which would work fine for fully AppService-controlled users, but possibly less well for double-puppeted users.

[tulir]

Thoughts on a special device to hold the information:

• a special device which allows keys to be sent/impersonated by a specific other user id (the bridge bot)
  • It should probably have the bot user ID, and maybe also the bot's cross-signing master key?
• preferably the special device wouldn't be required to have its own keys, so that clients wouldn't even accidentally try to encrypt messages to it
  • algorithms and keys would be empty in the device metadata, signatures could still be present for cross-signing
  • or if it makes things easier, maybe the device could only have a signing key, but no olm identity key?
• if the user holding the device has cross-signing keys, the special device data must be signed by the self-signing key
  • this would require the user to verify double puppeting devices. Verification could work by giving the bridge your recovery key, or just have an "allow" button in the client to sign the fake device entry created by the bridge.
• if the user has no cross-signing keys, then the data could maybe be trusted without signatures?
  • this would allow ghosts to not have any unnecessary keys, just the keyless device entry

[uhoreg]

One possibility is to create a special device to hold this information, which could have the MSC4261 do-not-encrypt flag. For double-puppeted users, this device would be controlled by the AppService.

Maybe something like setting the device keys to:

{
    "algorithms": [], // empty algorithms means the device doesn't do any encryption itself
    "device_id": "JLAFKJWSCS",
    "impersonator": { // full DeviceKeys object of the device that is allowed to impersonate, minus signatures
        "algorithms": [
            "m.olm.v1.curve25519-aes-sha2",
            "m.megolm.v1.aes-sha2"
        ],
        "device_id": "[bridge user's device ID]",
        "keys": {
            "curve25519:JLAFKJWSCS": "[bridge-device-curve25519-key]",
            "ed25519:JLAFKJWSCS": "[bridge-device-ed25519-key]"
        },
        "user_id": "[bridge user ID]"
    },
    "keys": {},
    "signatures": {
        "[bridge user ID]": {
            // normal device signature, and cross-signing signature from bridge's USK
        },
        "@...:example.com": {
            // cross-signing signature
        }
    },
    "user_id": "@...:example.com"
}

(Since algorithms and keys are empty for the device, we wouldn't need to have a flag telling people not to encrypt to this device, so MSC4261 would not be needed.)

(As I'm writing this, I see that tulir has added a comment, and it looks like we're thinking along similar lines.)

[tulir]

Wrote an MSC based on the comments: https://github.com/matrix-org/matrix-spec-proposals/pull/4350

[uhoreg]

https://github.com/element-hq/element-web/issues/30709 may need to be fixed for the MSC to work