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

TOFU (Trust on first use) + Verification #66

Open
ara4n opened this issue Jul 7, 2022 · 3 comments
Open

TOFU (Trust on first use) + Verification #66

ara4n opened this issue Jul 7, 2022 · 3 comments

Comments

@ara4n
Copy link
Member

ara4n commented Jul 7, 2022

Is your feature request related to a problem? Please describe.

E2EE is of very limited use if you can’t prove whether you’re talking to the right person or a MITM.

Describe the solution you'd like

Ability to view the olm public keys of the user you’re talking to, and be warned if they change, and have the option to verify them via device verification (and/or via some other out-of-band verification channel, e.g. an ID server)

This is quite subtle given trusting the website hoster to embed a non-malicious chatterbox means that even with verification, there's a risk of a malicious chatterbox being inserted into the mix if the host website wants to MITM its users. Suggestions welcome on how best to solve this one, as verification is useless if you can't trust the endpoint...

Additional context
https://news.ycombinator.com/item?id=32020476
https://twitter.com/MTRNord/status/1545089701698306050

@ara4n
Copy link
Member Author

ara4n commented Jul 8, 2022

(see also: element-hq/hydrogen-web#518)

@ara4n ara4n changed the title TOFU + Verification TOFU (Trust on first use) + Verification Jul 11, 2022
@bwindels
Copy link
Contributor

bwindels commented Jul 18, 2022

This is quite subtle given trusting the website hoster to embed a non-malicious chatterbox means that even with verification, there's a risk of a malicious chatterbox being inserted into the mix if the host website wants to MITM its users. Suggestions welcome on how best to solve this one, as verification is useless if you can't trust the endpoint...

So the threat model could potentially be that the user doesn't necessarily trust the embedding website, but they do trust element to host a non-backdoored chatterbox?

OTOH, the agent and bot they will be talking to (and receive the keys) will most likely be part of the same org that is embedding chatterbox in the first place.

@bwindels
Copy link
Contributor

Build should be reproducible, so I wonder if there is a way users could verify that a release of the source code on the GH repo is indeed what they are using.

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

No branches or pull requests

2 participants