Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We could cross-sign devices to aid trust when new ones join a room #2714

Closed
ara4n opened this issue Dec 7, 2016 · 22 comments
Closed

We could cross-sign devices to aid trust when new ones join a room #2714

ara4n opened this issue Dec 7, 2016 · 22 comments

Comments

@ara4n
Copy link
Member

ara4n commented Dec 7, 2016

At the moment we risk drowning users in unverified device warnings as per #2143, which is stupid given we can give some level of confidence that a new device should be trusted if it has been somehow cross-signed by a device that you already trust yourself.

@remram44
Copy link
Contributor

remram44 commented Jan 11, 2017

This is a good solution! It also opens the possibility for a "web of trust" in the future, where other user(s) you trust verifying people give you some trust transitively (like PGP; and definitely useful for bigger rooms).

@pierce403
Copy link

This opens up an attack where someone with temporary access to a phone or laptop could silently enroll a new malicious device, which isn't a huge tragedy, but should be considered.

I notice that my own devices in Riot aren't automatically verified, which is nice. Maybe when an old device sees that a new device has been enrolled, they should get a popup like

A new device "<devicename>" has been added to your account. [endorse][ignore][remove]

"Ignore" just does what today's default is. "remove" removes the key from the account, and "endorse" verifies the key for yourself, and emits a message to all the e2e rooms you're in that looks something like

<nick> (id) has endorsed "<new device>" with "<old device>"

Then, there could be an option, per user, called "Trust cross device endorsements", which is enabled by default, and if enabled, the endorsement message, and the warning message I propose in #2143, could silently disappear.

@remram44
Copy link
Contributor

Requiring people to verify each device separately seems a bit unrealistic IMHO. And since other people will happily encrypt for that new device regardless of whether it is verified, some validation is better than none.

@andrewgdunn
Copy link

May consider signal's method of device linking from a UX standpoint.

@vext01
Copy link

vext01 commented Mar 9, 2017

I agree that this would be useful.

I have a friend with 2 devices, and I have 3. Each of our devices has to sign each other device, which is awkward and I also think a barrier to entry for non-technical users.

Thanks

@tessgadwa
Copy link

tessgadwa commented Mar 9, 2017 via email

@erdii
Copy link

erdii commented Mar 10, 2017

You can configure your Riot instance, to only send messages to trusted devices in the settings.

@schnuffle
Copy link

@erdii i used this option. Good from a security point of view but it adds even more confusion, when you start searching for the reason, why no more messages are send.
I don't know exactly anymore, but i had riot on one device telling me there're unverified devices, on another riot it just silently did not send the message.

I recently added some non geek friends to my HS and the first lesson has been:

"access your account from one device only or you'll get negative feedback".

Sooner or later they will complain about missing mesages. So they all even don't know there's a web client :)
They get the idea of having to trust once to be sure about the others identity, anything on top of that and you loose them.
On the other side, they understood the concept of having to trust each new device they access their account with. So it seems, moving the trust modell to a concept of "user adds trust to his devices" is better understood by non it people.
I see a possible attack vector, so it's not that i think it's better, just that it's better percieved by my community of non technical people.

@erdii
Copy link

erdii commented Mar 11, 2017

I think signal and keybase have some kind of key-tree magic going on, so the other users only trust one pubkey and you can have multiple device keys behind that pubkey. Something like this would be great IMO because it would shift the device-trust hustle to the user owning the devices.

@ara4n
Copy link
Member Author

ara4n commented Mar 11, 2017

the problem is that sometimes you /do/ want to trust/distrust specific devices - hence the idea of cross-signing rather than having a formal hierarchy. But all options are still on the table here :)

@erdii
Copy link

erdii commented Mar 11, 2017

Is the requirement to be able to distrust other user's devices or is it enough to be able to distrust one of your own devices and your chatpartners stop encrypting for that device too?

@pik
Copy link

pik commented May 4, 2017

How is trusting devices based on other users any improvement from simply the user cross-verifying their other devices from their primary/verified deice?

@ara4n
Copy link
Member Author

ara4n commented May 10, 2017

crosslinking to #2142 (general 'improve verification')

@go2null
Copy link

go2null commented Oct 17, 2017

One option would be to create a new intermediate permission level that corresponds to trusted by owner.
(Right now we have trusted by me and not trusted by me.)

This could be exposed in the main Settings and Room Settings as, for example,

  • Trust new devices verified by the device owner

It could also be exposed the User Details sidebar USER OPTIONS section as, for example,

  • Trust new devices verified by the user

@fearedbliss
Copy link

fearedbliss commented Oct 2, 2019

What's the current proposed solution for this? At the moment I've been using Matrix for about a year now and a huge advocate for it, I have my family, and a lot of my friends on it as well, however one thing that is a huge UX problem is that we basically have had to stop using verification completely since the most important thing for us is simply to encrypt our conversations, and it's a futile effort for us to do verification. If any on of us log into the web ui (Which we basically avoid as much as possible for the same reason - and just use our mobile devices), we get a new device id (as per design), after this happens if any of us contact each other we are displayed with the "Unverified device, verify, or use legacy verification" etc messages. At that point since it's a futile effort, we just click send anyway. Using only the mobile devices really limits the power of using Matrix and it has an extremely negative UX. Just thinking about logging out is problematic because it means that everyone will get an unverified message pop up which is really stressful for everyone involved. As what people said before, using a strategy similar to Signal or WhatsApp where people are alerted of a device change would definitely help.

This would of course need to be added to riot-web, riot-android and riot-ios.

@gerroon
Copy link

gerroon commented Oct 2, 2019

@fearedbliss

This kills me too :( I hate it, my users hate it

@uhoreg
Copy link
Member

uhoreg commented Oct 2, 2019

The proposed solution is matrix-org/matrix-spec-proposals#1756 and the implementation is currently being worked on. It has been implemented in matrix-js-sdk and synapse (pending review), but the UI part for riot-web still needs to be done, as well as implementation in riot-android and riot-ios.

@fearedbliss
Copy link

@uhoreg thanks for the reply! I'm looking forward to it :).

@tuxayo
Copy link
Contributor

tuxayo commented Dec 1, 2019

Is there a place to follow the progression of the work on

  • matrix-js-sdk
  • synapse
  • I guess for Riot it should be here right?

@jryans
Copy link
Collaborator

jryans commented Dec 2, 2019

The cross-signing project is tracked as a set of user stories.

We use a custom dashboard to view the status of all issues in the project. (It requests approval to access your GitHub account because GitHub API request limits would not allow it to load otherwise.)

@tuxayo
Copy link
Contributor

tuxayo commented Jan 24, 2020

Thanks a lot, it really shows the huge work for this.

@uhoreg
Copy link
Member

uhoreg commented May 5, 2020

I think we can close this one now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests