MSC2882: [WIP] Tempered Transitive Trust #2882
Conversation
uhoreg
changed the title
uhoreg
changed the title
|
I thought that the modern Matrix way of providing such a stream of data would be to have a special-purpose room for the user's public verifications, no? This would also solve the limited distribution problem by, for example, having an additional invite-only stream? |
|
That would be the future-Matrix way; "*-as-rooms" is still being worked on. We may switch to that for key distribution in the future, but it's not ready for that yet, and it would be a completely separate MSC. |
| @@ -0,0 +1,213 @@ | |||
| # MSC2882: Tempered Transitive Trust | |||
There was a problem hiding this comment.
If you publish now signatures visible for others, the need to unpublish signatures you previously published is greater and greater. Perhaps it is a good idea to tackle that, too? Maybe in another MSC?
There was a problem hiding this comment.
Yup, good point. It may make sense to include it in this MSC, but we'll see how it goes.
| making public signatures on other users' master or public user keys. The | ||
| public part of this key can be uploaded to `POST /keys/device_signing/upload` | ||
| by using the name `public_user_signing_key`. When uploaded, it must be signed | ||
| with the user's master key, and must have `public-user` in the `usage` |
There was a problem hiding this comment.
#2757 also introduces a new key, an event-signing key. Implementations might want to create both keys at the same time to only have to do one migration for both features.
| making public signatures on other users' master or public user keys. The | ||
| public part of this key can be uploaded to `POST /keys/device_signing/upload` | ||
| by using the name `public_user_signing_key`. When uploaded, it must be signed | ||
| with the user's master key, and must have `public-user` in the `usage` |
There was a problem hiding this comment.
For consistency, shouldn't the usage be called public_user_signing?
| ``` | ||
|
|
||
| To avoid abuse by flooding a user's devices/keys with signatures, each user may | ||
| only make one public signature on another user's device/key; if they make |
There was a problem hiding this comment.
What limits, if any, does this bring?
| ### Trusting trust | ||
|
|
||
| If Bob wants to trust Alice's signatures for some users, he will store | ||
| information in the `m.trust.transitive` event type in account-data. This |
There was a problem hiding this comment.
Account data is private anyways, shouldn't signing with the event signing MSC be sufficient? Otherwise we also end in a situation that the user will have to enter their recovery passphrase on every single device every time they updated their trust model.
As only the homeserver admin could review whom bob trusts, one could argue that that isn't much of a breach as the homeserver admin sees whom bob communicates with, anyways.
|
|
||
| ## Potential issues | ||
|
|
||
| When a user makes their signatures public, this is visible to all Matrix users. |
There was a problem hiding this comment.
What if signatures are only made public to all users of a specific homeserver?
| considerations" section, but would increase the complexity. | ||
|
|
||
| Rather than replacing `POST /keys/signatures/upload` with a new endpoint, we | ||
| could just use the current `POST /keys/signatures/upload` endpoint and have the |
There was a problem hiding this comment.
or, if the keyword public and private are lacking, it does the fallback by key type
| @@ -0,0 +1,213 @@ | |||
| # MSC2882: Tempered Transitive Trust | |||
There was a problem hiding this comment.
Fluffychat at least currently only subscribes to the device list of people you share an e2ee room with, currently.
If soru understands this correctly, this will also have to expand to all people who are part of a signature chain you want to potentially verify, is that correct?
There was a problem hiding this comment.
Yes. I think this is also a limitation on the server side, where it will only send you device updates from people that you share rooms with. I should probably note that in this MSC somewhere.
It may or may not be a problem in practice since you'll want to verify people in the signature chain, which generally involves creating a DM with them.
There was a problem hiding this comment.
It'll be a problem as soon as there is an additional hop: we don't only trust who bob trusts, we also trust people who bob trusts and who those trust. This MSC doesn't cover that usecase, so maybe it is enough to state this "for later".
Sorus usecase is again with a "trust management" of a company, that if you query the "trust management" keys separately and verify them somehow, without needing a DM (remember the talk / suggestion of other kind of signatures to master keys we had?) an external person can easily know who all in that company is trusted, without having to create a DM with "trust management"
| @@ -0,0 +1,213 @@ | |||
| # MSC2882: Tempered Transitive Trust | |||
There was a problem hiding this comment.
Just for some clarification help:
Let's say we have a company with a trust managing team, said trust managing team signs the master key of all their employees with their public user signing key.
Now, if someone from outside the company wants to contact that company, after verifying the trust management team somehow (up to the future / a future MSC?) they can then see that the specific device was signed by trust management and trust management is valid. What they CAN'T do, though, is query all signatures that trust management made, so they CAN'T just query the entire list of employee accounts, as the signatures are attached to the device that got signed. Is that correct?
There was a problem hiding this comment.
Yes. If "Trust Management" signs Alice's key, then Bob will only see that signature when he queries Alice's key. Nothing from "Trust Management" will point to Alice just by querying "Trust Management"
| \[FIXME: define how `m.trust.transitive` is formatted. Initial ideas are | ||
| something along the lines of having a mapping of trusted users to users that | ||
| they are trusted for (e.g. I trust Alice to verify `@carol:matrix.org` and | ||
| `*:example.org`), plus a list of exceptions (e.g. even though I said I trust |
There was a problem hiding this comment.
perhaps also a user suggesting what to trust for them, that way for e2be the bridge bot could suggest @_discord_*:example.org or something
There was a problem hiding this comment.
though it might be easier to only add that once profiles-as-rooms is a thing
There was a problem hiding this comment.
Yup, agreed on both points (that it would be a good feature, and that it may be better to wait for profiles-as-rooms).
| \[FIXME: define how `m.trust.transitive` is formatted. Initial ideas are | ||
| something along the lines of having a mapping of trusted users to users that | ||
| they are trusted for (e.g. I trust Alice to verify `@carol:matrix.org` and | ||
| `*:example.org`), plus a list of exceptions (e.g. even though I said I trust |
There was a problem hiding this comment.
Another good thing might be, again in profiles-as-rooms, define in a signed event whom all to use as trust source, too.
Example of what soru means:
A company has a trust management, with which each new employee verifies. Now, the company grows, and the need for multiple trust managements arise. So, the company sets up a "Main Trust", with sub-trust-managements for different parts., so like
Main trust
/ \
Trust A Trust B
A new employee should now be able to verify with either Trust A, or Trust B. Those, in turn, say things trusted by "Main trust" are to be trusted, and "Main trust" says people trusted by both "Trust A" and "Trust B" are to be trusted.
This could be modeled by having a signed event in profile-as-room with an array of MXIDs whos transitive-trust level are to be seen the same as your own.
| # MSC2882: Tempered Transitive Trust | ||
|
|
||
| There are many situations in which two people are unable to verify each other | ||
| directly, but they both trust a third party to mediate the verification. For |
There was a problem hiding this comment.
I don't think we need a requirement that they both trust the middleman to mediate? If Alice wants to verify Bob via Michael, then Alice needs to trust Michael, but Bob doesn't get a say in whether Michael signs and publishes Bob's key?
| all employees. | ||
|
|
||
| In order to do this, we need to a mechanism for users to share their | ||
| verifications with other users. However, this sharing needs to be done in a |
There was a problem hiding this comment.
Do these need to be users? I think the common case is for these to be more organisation level stuff, e.g. a business publishing a list of signed employee keys. It would be nice to be able to support very noddy implementations that don't require a real account and client
There was a problem hiding this comment.
It would be trivial to make a trust-signing-only client and making it users reduces the need to introduce a new entity which can have device keys etc.
If you are more thinking about third party signatures, that's a separate MSC: #2961
There was a problem hiding this comment.
Yeah, I guess I'm mostly just saying let's keep that use case in mind. Especially if it actually becomes the dominant use of this feature (which I think it very well might).
| a signature of Bob's master key signed with her public user signing key. | ||
| Similarly, she can also publish the fact that she trusts Bob to verify other | ||
| people by upload a signature of Bob's public user signing key signed with her | ||
| own public user signing key. \[FIXME: Should we have some way for Alice to |
There was a problem hiding this comment.
I think we need to be careful here, handing out trust is quite a big deal to begin with, and doing so transitively to large degrees is going to lead to some surprising situations where someone in Alaska has accidentally verified a scammer and now I trust the scammer because I'm friends of friends of friends of someone in Alaska. I don't really think saying that you should trust who you trust really works here.
| if, e.g. all of a company's employees are in a common company chat room, but | ||
| could allow a server admin to lie about someone being in the room so that you | ||
| will trust a signature on that user. Specifying multi-hop trust may be | ||
| complicated.\] |
There was a problem hiding this comment.
So this actually touches on my main concern with transitive trust, and that's that verification is really the linchpin of our security model: if someone manages to break it then it opens up lots of attacks. This then leads to some competing concerns:
- we're saying you should be really careful who you trust, and that you should trust how they handle security of their devices; and
- we want to allow users to easily verify organisations and large groups of people at once, to avoid everyone having to manually verify each other.
Now, saying that we only trust Bob to verify on behalf of *:example.com sort of alleviates this, but a) doesn't help for groups/organisations that have users from multiple (or event just public) homeservers.
One suggestion here would be that all transitive trust are associated with a label (that the user can select, though the remote user can give a default), and every time we render that user in the app we include the label, e.g.:
or with some other wording.
If we have verified the user then we don't show a label.
| if, e.g. all of a company's employees are in a common company chat room, but | ||
| could allow a server admin to lie about someone being in the room so that you | ||
| will trust a signature on that user. Specifying multi-hop trust may be | ||
| complicated.\] |
There was a problem hiding this comment.
We should be explicit that we trust local verification over transitive ones, i.e. if we have verified Bob then we ignore any other claims for Bob (concretely, if a transitive user has verified a different key than we have, we should not trust the other key)
| allows for multi-hop transitive trust: by publishing the fact that Alice trusts | ||
| Bob to verify users and to sign them with a given public user signing key, | ||
| Carol can verify with Alice and (if she believes that Alice is a good judge of | ||
| character) can then trust the users that Bob has publicly signed. |
There was a problem hiding this comment.
If Bob trusts Alice to verify people, and Alice uploads new signatures, how does Bob get those updates? Do those get pushed to him?
There was a problem hiding this comment.
Probably the same as with x-singing: Bob trusts alice to verify people, and alice adds a signature to....clair.
If Bob already has an open room with Clair, bob will get in his /sync that clairs device is out-of-date and re-query it, including alice new signature
| allows for multi-hop transitive trust: by publishing the fact that Alice trusts | ||
| Bob to verify users and to sign them with a given public user signing key, | ||
| Carol can verify with Alice and (if she believes that Alice is a good judge of | ||
| character) can then trust the users that Bob has publicly signed. |
There was a problem hiding this comment.
Should we add an option for a single snapshot approach? I.e. Bob can verify everyone who Alice has currently verified? That way you can a) manually see who Alice has verified (you could even have an advanced mode where you select a subset of users to copy across), and b) you don't need to worry about Alice doing something stupid later.
There was a problem hiding this comment.
Isn't that an implementation detail, for when a client generates signatures of other devices directly?
There was a problem hiding this comment.
Yup, though I think its probably worth calling out explicitly as something clients can/should support
turt2live
added
the
needs-implementation
|
This may be an entirely naive suggestion, but would it be possible limit the web of trust to spaces? E.g admins of a space pin/add their transitive public key to the space, and people who are in the space then trust that key. This allows for closer management of the 'web of trust', getting around the "one dude in Alaska trusts a scammer and then the whole world is now open to them". |
Rendered
would fix https://github.com/matrix-org/matrix-doc/issues/1886