MSC4350: Permitting encryption impersonation for appservices #4350
Conversation
Signed-off-by: Tulir Asokan <[email protected]>
tulir
added
e2e
proposal
There was a problem hiding this comment.
Implementation requirements:
- Bridge or other appservice making use of impersonation
- Client that validates impersonation requirements
- Server that exposes
signaturesproperly
| * the user who owns the impersonatable device has cross-signing keys and the | ||
| impersonatable device is not signed by the user's self-signing key |
There was a problem hiding this comment.
What happens if there are no cross-signing keys?
There was a problem hiding this comment.
Then the device is trusted with just the impersonator's signature
There was a problem hiding this comment.
Have added a paragraph below the bullet to call it out explicitly
| The `algorithms` and `keys` fields are still present and required, but MUST be | ||
| empty when an impersonator is defined. Because there are no keys, `signatures` |
There was a problem hiding this comment.
What does this mean? Both fields need to be set to an empty list?
If so, I think it would be better to say it like that explicitly. And second, why require them to be defined but be an empty list?
There was a problem hiding this comment.
The fields are currently required, so the main reason is to avoid changing that. They could totally be removed too if that's preferred, I was mostly thinking about what would cause the least unexpected behavior in old clients.
|
|
||
| The device owned by the ghost user (or real Matrix user in case of double | ||
| puppeting) with the `impersonator` field will be referred to as the | ||
| "impersonatable" device, while the bridge bot's device is the "impersonator" |
There was a problem hiding this comment.
Given that the "impersonatable device" has no keys, in what way is it a device being impersonated? Rather, I believe "impersonatable device" is a bit of a misnomer; it is simply a way for a user to specify a foreign device that is allowed to impersonate them. It is the user being impersonated, not any specific device of theirs.
There was a problem hiding this comment.
Yeah need to figure out some better terms. The impersonator is the bridge bot's device which is obvious enough, but I'm not sure what to call the device entry that points at the impersonator without it being confusable with the impersonator itself.
| The requirement to cross-sign the impersonatable device could be bypassed by a | ||
| malicious server that hides the user's cross-signing keys. However, hiding | ||
| cross-signing will also prevent other devices of that user from working, so it | ||
| should be easily noticeable. |
There was a problem hiding this comment.
I think this is concerning and should likely be fleshed out more. Can you spell out why hiding the cross-signing keys would stop other devices from working?
There was a problem hiding this comment.
If you require cross-signing for real devices with keys (as per MSC4153), then suppressing cross-signing keys server-side will make clients stop encrypting messages to those devices and hide messages from those devices.
There was a problem hiding this comment.
The security consideration now specifically mentions MSC4153 as the reason why it should be safe
Rendered