MSC1680: cross-signing

[uhoreg]

PR for #1680

Rendered: https://github.com/uhoreg/matrix-doc/blob/cross-signing/proposals/1680-cross-signing.md

[ara4n]

Hm. There's something about the idea of the assertion DAG spanning multiple users which feels wrong here - the idea of User A publicly publishing that they have verified one of User B's devices is a very strong metadata leak.

Or is the idea that the cross-user attestations aren't published, but are kept personal to a given user (albeit trusted on their server?)

[ara4n]

our verification mechanisms are symmetrical so presumably the signing graph shouldn't actually be directional? (and could also be cyclic unless we explicitly stop cycles...)

[uhoreg]

The verification mechanisms are symmetrical, but the attestations are directed, as one device of the pair might not publish their attestation.

I should probably also spell out that the graph, although is directed, is not necessarily acyclic, unlike every other time that "directed graphs" are mentioned in Matrix.

[ara4n]

i'm failing to think of a reason why you wouldn't publish symmetrical attestations between your own devices. and (unless i'm misunderstanding everything), you shouldn't be ever publishing attestations about other people's devices to anyone but yourself?

[uhoreg]

The attestation graph has to be directed, otherwise a malicious user could create a fake device under Alice's account and publish an attestation for one of her other devices, and trick the other devices into thinking that the trust is mutual.

[ara4n]

To preserve metadata privacy, I think this needs to be constrained further (as per https://github.com/matrix-org/matrix-doc/pull/1681/files#r219310880): If Alice is wondering which of Bob's devices she should trust, she should see only the attestations she's made (including those about others' devices)... and only the attestations that Bob has made about Bob's own devices.

[uhoreg]

Right, this is probably a bit confusing because I'm just plopping an addition in, with no context whatsoever, and so it probably would benefit from an example, which I'll add to the doc. But the basic idea is that the attestations array is in the context of one of Bob's devices, and so only contains attestations about that device. So when Alice queries the information on Bob's devices, then it will return Bob's device, and attestations made about that device made by Alice's devices and Bob's devices, but not any attestations made by Carol about Bob's devices.

As a result of this, attestations made by Alice never need to leave Alice's server, which I think addresses your first comment.

[ara4n]

i'm not sure, as in your model Bob's attestations about Alice's devices get published to Alice here (and thus leave his server). Surely Alice should only care about her attestations about Bob's devices (and how Bob has cross-signed his own devices), rather than Bob revealing unnecessarily which of his devices has attested to Alice?

Or perhaps this doesn't matter much given Alice's server will already know about her attestations about Bob, and we're not trying to encrypt the attestations on the server.

[ara4n]

Are you saying that we should distinguish between devices which were logged out but are still trustable versus ones which were logged out but whose trust should be explicitly revoked? This feels like we could end up with three classes of logouts:

• soft-logout (where the device doesn't delete any data, is still trusted, but the user needs to be reauthenticated as a precaution after doing something like changing their password)
• trusted-hard-logout (where the device destroys all local data and logs out the user... but its attestations are still trusted)
• untrusted-hard-logout (same, but attestations now revoked).

I wonder if this is overengineered - do we really need the trusted-hard-logout state? It feels that if you have abandoned a device and logged it out, its attestations may not be worth very much any more, even if they seemed okay at the time...

[uhoreg]

Are you saying that we should distinguish between devices which were logged out but are still trustable versus ones which were logged out but whose trust should be explicitly revoked?

Yes, that's the idea. I'm not sure if it's needed, but it's something that we were thinking about when we were brainstorming. I think the situation we were thinking of was where Bob cycles through devices very quickly. So Alice verifies Bob's Osborne 2. The following week, Bob replaces his Osborne 2 with a Dynabook, and the week after, Bob replaces is Dynabook with a PADD. Alice logs on for the first time since verifying Bob's Osborne 2, and is unable to trust Bob's PADD, because the Dynabook and Osborne 2 are logged out.

[ara4n]

For simplicity, shouldn't we mandate this only includes the ed25519 key? (or whatever we actually verify when we do QR or interactive text based verification)?

[uhoreg]

For simplicity, shouldn't we mandate this only includes the ed25519 key?

Yeah, we should probably say that somewhere, but I'm not sure where is the best place. The idea is that, some time in the future, we may no longer be using ed25519, so we need to be able to sign other types of keys here.

[ara4n]

sure, but the important thing is that we're attesting the device's signing key rather than the identity key (whatever curve that might use)?

[uhoreg]

Yup. Wording suggestions welcome. 😉

[ara4n]

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.

[uhoreg]

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.

[jcgruenhage]

The client could prompt the user whether it should do it or not.

[anoadragon453]

Need to ensure this is presented in a friendly way to non-techies though.

[jcgruenhage]

That would make working in encrypted work chats with lots of people a bit complicated.. Where does this limitation come from? As long as the users know how the trust is established, going over multiple users should be okay IMO

[uhoreg]

Normal web-of-trusts (webs-of-trust?) are a bit tricky, because you need to determine how much you trust other people to have verified other people. For example, cryptogeek Alice might be very strict about checking identities, and may have verified Bob's device, but might not trust Bob to have properly verified Carol's identity, or may not trust him to not be maliciously signing fake devices for other people, so will not trust Bob's attestations. However, Bob, knowing how much of a paranoid cryptogeek Alice is, and knowing that she's a whitehat, might have no problems trusting Alice's attestations.

In the case of cross-signing, we make the assumption that people are generally sane and will only verify their own devices only they actually belong to them, as signing a fake device will harm themselves.

It may be possible that we implement a more extended web-of-trust later on, but for now, I think it's better to keep it simpler.

[jcgruenhage]

What about still saying a device is unverified, but showing the user a dag of attestations from themselves to the other device? The more different paths there are, and the shorter they are, the more trustworthy a device would be. I think it's fine to limit cross signing to own devices for now, but I'm not sure that is a limitation that should be made at the protocol level instead of the UX level.

[anoadragon453]

A more advanced WoT trust like that would be satisfying, but I do worry about the users who just verify devices because they like how the green lock looks, without actually checking it.

I also don't want to verify my mother's devices meaning that I trust all the random trust decisions she's making.

[jcgruenhage]

I don't want to verify my peers random devices either, but that just means I have to live with all the yellow exclamation marks.. As I said, I'd limit that via UX, but I wouldn't want to have a more advanced WoT blocked by protocol decisions worrying about what some users might do to avoid bad UX (because honestly, verifying devices to get green locks sounds like bad UX to me)

[ara4n]

yeah, the big concern here for me is the fact that it broadcasts metadata to all users on the network. Just because you’ve verified Lenin’s keys doesn’t mean that I want you know that I have too...

[jcgruenhage]

I am not saying we should publish any attestations for devices of other people here, I am just saying we shouldn't forbid that in the protocol, so that a more generalized WoT would be a client side extension, not a server side one.

[uhoreg]

It needs server-side changes anyways, since the server needs to control what attestations it shows to users, and what attestations it forwards to other server, so it can't be a purely client-side extension.

[jcgruenhage]

I thought the query endpoint would be used to query the attestations published by a user? Filtering out any that try to do attestations for devices not controlled by that user is something the client could do.

[uhoreg]

The query endpoint is used to query the attestations made about the device/user, not made by the device/user.

[jcgruenhage]

We should probably include old devices (and the point when they were removed) anyway, for people who scroll back up. We might even want to store attestations from the new devices signing that the old device was trusted in some timeframe, so that new devices can read history and know that it's okay.

[erikjohnston]

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:

• How does this work with recovering an account (via the backup)? If you've lost all your devices then you won't be able to verify your new device, even though you've got all the backed up E2E keys.
• As noted we'll need to be careful removing a device, since removing edges may disconnect the graph. This can easily happen if you e.g. a) register on an ipad, b) login and verify on a laptop and then c) login on a phone and verify against the laptop, at which point logging out of the laptop will break the graph. However keeping around the attestations for logged out devices that are still needed to keep the graph connected feels like it could easily end up causing old users have large attestation graphs.
• Asymmetric attestations are going to cause all manner of confusion if they're allowed to happen, since if user A on their different devices each verify different devices of user B's, A will see different state on each of their devices. You can probably ensure that all of user A's devices trust the same devices, but you would still have the same problem across different users.
• In this model a user is verifying a particular device, which may very well be a fairly ephemeral concept depending on how often they change devices/relogin etc. This makes it difficult to try and verify a particular user. If two users try and check that they've verified the same "user" of a third account, they can't simply compare the key they've individually verified (indeed, the two users may only partially agree about which devices should be verified due to the asymmetry). Similarly, when users want to publish their keys on e.g. their website, they would need to pick a device and ensure that they keep the website up to date whenever they change that device.
• Requiring clients to do graph algorithms in the presence of cycles feels like quite a burden. Yes, end to end is quite complicated anyway, but this feels like quite a large potential foot gun.

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

1. Included in the key backup to the server. Though we may instead want to use the master key to encrypt the backup.
2. Give all verified devices a copy of the master key, this feels a little icky but probably fine for most use cases and allows the UX to be seamless.
3. Have the user store it manually, e.g. print it out and store it on a safe, or use a hardware key. This would allow users to keep their identity (i.e. other users won't need to reverify them) if they lose or logout of all their devices.

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

[uhoreg]

Thanks for the review, @erikjohnston.

How does this work with recovering an account (via the backup)? If you've lost all your devices then you won't be able to verify your new device, even though you've got all the backed up E2E keys.

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.

As noted we'll need to be careful removing a device, since removing edges may disconnect the graph.

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

Requiring clients to do graph algorithms in the presence of cycles feels like quite a burden.

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 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?

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

[erikjohnston]

How does this work with recovering an account (via the backup)? If you've lost all your devices then you won't be able to verify your new device, even though you've got all the backed up E2E keys.

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

As noted we'll need to be careful removing a device, since removing edges may disconnect the graph.

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

That doesn't really help when new users want to verify the devices though.

Requiring clients to do graph algorithms in the presence of cycles feels like quite a burden.

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

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.

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?

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

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

[richvdh]

I've re-skimmed this but it feels like it is being superceded by MSC1756 (which generally does feel nicer), so I haven't paid it too much attention. I assume someone will put me right if that is an error...

[richvdh]

Suggested change

	don't want to other devices to continue to encrypt for that device, so maybe
	don't want other devices to continue to encrypt for that device, so maybe

[richvdh]

Suggested change

	A malicious hommeserver is able to prevent distribution of revocations. For
	A malicious homeserver is able to prevent distribution of revocations. For

[richvdh]

broken link here

[uhoreg]

Dropping this in favour of #1756