MSC1680: cross-signing #1681
this is looking super-promising to me, modulo the general metadata privacy thing i've highlighted in the comments.
Something that I thought about a bit in the past was whether we should consider storing the attestations encrypted on the server (a bit like we do e2e keys) to protect their metadata - e.g. have Alice store her attestations in a general encrypted store that only her clients have the keys to, but then use PKI to let Bob selectively decrypt whichever keys he needs to follow the cross-signing DAG. Thus avoid the servers spying on which user is attesting to whom.
However, given the server can just inspect the network traffic or room metadata to see who's talking to who, i'm not sure this buys us much other than overengineering. But just wanted to note it down for posterity as a random idea.
Pushed new version, which should make things clearer.
Regarding encrypting the attestations, I think it would be really hard to do properly, since you don't know in advance what devices will need to decrypt it, as new devices will be created after the attestation is published. It seems like it would make things a lot more complicated.
Hey, sorry for not getting to look at this sooner, and sorry for the wall of text. This does look like an entirely sensible way of implementing cross signing.
However, a few thoughts I've had while reading through this are:
Broadly I'm worried that while this will certainly work (and in some ways quite an intuitive and elegant way of doing so), it also locks us into a fairly convoluted verification model from a UX perspective (and potentially a security perspective).
I wonder if we can tweak the model slightly and have a master identity key for the user, which is then used to sign device keys? This would make things a lot simpler, except that we'd need to a) figure out where the master key is stored and b) ensure that users can update their master key.
Storage of the master key could be done in a number of ways (or any combination of):
(If the master key is only ever stored off device, this would allow a very secure setup where an attacker would need access to the hard copy of the key before they could hijack the account).
TL;DR: This definitely feels like the right direction for solving the problem via cross signing, but has unfortunately made me doubt whether this really is the right way to go in terms of final UX.
Thanks for the review, @erikjohnston.
There have been thoughts about being able to have a virtual device (whose key gets stored (encrypted) server-side) which is persistent and that can be used for cross-signing. So all of a user's real devices can sign the virtual device and (if they fetch and decrypt the keys from the server) vice versa. I think that this is similar to your "master identity key" idea.
Yup. That's kind of similar the question at https://github.com/matrix-org/matrix-doc/pull/1681/files#diff-63d9ae063d120a03159774aff2c55af5R63, but a client could decide that once a device trusted via cross-signing, it could be permanently marked as "trusted".
I don't think it ends up being too bad. Cycles can be handled as just marking a node as "visited", and not re-visiting an already-visited node. The graph search algorithm gets slightly long (implementation in js-sdk here: https://github.com/matrix-org/matrix-js-sdk/pull/795/files#diff-fa4472db829c5a59596c29a2f43e8f9cR1243) but I wouldn't characterize it as being too difficult. (Though, having done graduate studies in graph theory, I may not be the best judge of what's "difficult".)
I'd be worried about having a single immutable master key that couldn't be removed, but having a virtual device that could be revoked and re-created like a normal device when needed, I think would work well. (It might also help with receiving encrypted messages when the user has no devices logged in.)
Yup, though you would need to special case the virtual device everywhere to ensure nothing gets confused and thinks its an actual device (e.g. you don't want users seeing it on the device lists and deleting it).
That doesn't really help when new users want to verify the devices though.
It just strikes me as one of those things that is easy to just get wrong without really noticing, and a bug here would undermine the entire security of the system.
There's no reason why you couldn't mutate or revoke the master key in similar ways as you are proposing for attestations. TBH I'm more comfortable with the security around revoking the master key than individual attestations, as if you revoke the master key everyone will see that you have been compromised and should reverify against the new key. OTOH, if one of your verified device's are compromised you need to ensure that you revoke every single attestation that leads to that device, and hope that other users haven't verified against that compromised device (though I guess in practice here you'd just rely on the server doing the right thing when you hit /logout/all). Nonetheless, it becomes subtle trying to differentiate between "this device has been logged out nicely" vs "the device was logged out due to being compromised".