element-hq
TOFU in E2EE
I am getting an increasing pattern of people trying to verify me in-band, and it's not because they are confused and think that in-band verification is somehow safe - but because they are trying to get trust-on-first-use (TOFU) semantics:
"I want to know when your devices change. So i'm verifying your current ones. I don't particularly care about verifying you in person".
Therefore, I am wondering whether we're making an error in not supporting TOFU.
e.g. we could provide it with:
- black shield == "trusted but not verified"
- green shield == "trusted and verified"
- red shield == "untrusted device added"
So you start off implicitly TOFUing people with a black shield, but if they then add a bad device, it'd go red. Similarly explicitly verified users would be green, unless they add a bad device, where they'd go red.
The current behaviour (i think?) is that if you haven't verified someone, we ignore whether they add trusted or untrusted devices to their accounts.
The potential issues with this are manifold. With broad strokes:
-
TOFU has proven useful for systems to trust other systems, where a user parsing that trust has a mental model of the entire design of those systems. This isn't the case for end users trusting each other, compounded more so when considering our wide user base (non technical to very technical) and wide use cases (small to large rooms). Fundamentally, TOFU could potentially serve the more technical users who are able to denaturalise the trust model, but there is a lot to untangle to qualify users that don't fall into this bucket, of which there are many.
-
It's antithetical to the current trust model of black shields indicating encryption is enabled, and red & green shields indicating the status of verified users. We're using verification as a heuristic to qualify whether a user cares about the other users devices at all. Switching to TOFU as described heavily risks putting us back to where Riot was 6 months ago where the common case is that most users see lots of red warnings and therefore perceive that "encryption is broken" in Matrix.
-
In order to make a more TOFU like model work, good device hygiene is imperative, and the UX we have today doesn't serve this goal as well as it could, so we'd need to iterate there also.
If we want to qualify TOFU further, I'd advocate for us to kick off with a workshop on this issue first to better qualify the user problem and the shapes of potential solutions.
We talked this through, and conclusions were:
- We need to track whether a given cross-signing assertion is tofu or explicitly verified via SAS.
- We can put this on the cross-sign signature data structure somewhere.
- We only need these tofu cross-sign signatures for people we explicitly trust as tofu - we don’t want to do it to everyone we find; only to people we actually care about.
- We show these people as half-verified in the UI somehow (e.g. half-green shield, or possibly a blue shield).
This looks very promising. A bit of bikeshedding: If you don‘t trust a key the first time you see it, but when the user opts into it, that is more like "pinning" and not really tofu.
I am not sure what you mean with "people we actually care about". But I think there should be an option to enable pinning the keys of anyone we see (or send a message to? or get a messag from?). But I strongly agree that this option needs to be off by default.
I still believe this would be a really nice and important addition.
(As a side note: Does a signature event have a time stamp? If no I think especially for tofu that would be quite useful to have an information like "This key is being trusted since 3 months ago")
I realize that there are is a lot of different and important work is going on. But it would be really nice to know if and where you have this on the roadmap.
Also feel this is an important feature for users to have, so the spec should allow for such, to be implemented. Therefore although I understand, now is not really a priority, nonetheless should be added to the roadmap. Cheers . ¦3<RELATIVISM.
I just watched Matrix Live with the Element Roadmap. Thank you for the tour! I am really amazed by all the features you are planning and I realize that you have a lot of issues to think about and to prioritize.
Still I couldn‘t fail to notice, that this issue is not on the Roadmap. So I just wanted to try to bump this again on your radar. Although I feel a little bad about being nearly the only person bugging you about this. I am pretty sure that this is feature a lot of people (which know how E2E works) would really appreciate.
Now, normally when I wish for something in an open source project I try not to annoy people about, but to actually do/contribute something. Sadly for this issue I wouldn‘t know where to start. This needs UX, design, spec, client and (maybe) server considerations and is not a very small effort in general.
What I can do (short of founding a startup and collecting venture capital to pay you for working on this) is elaborate a bit more on how exactly I would imagine this feature. All of this is up-for-debate, but I’d like to present a design, which I think would work nicely without causing any harm:
The overall idea here is, that this feature is only useful or should be displayed to users who would do a proper verification if they had a secure out-of-band channel, and understand what that means. The threat model here is to prevent a mitm attack by a rogue device in the time window between first online contact/time of pin with a user and the first time where you have the ability to verify them (which can be never, either by circumstance (imagine you get to know a person on the internet, crazy, right?) or because it would be too much effort.) While pinning is vulnerable to a mitm at the time of first contact, this would decrease the attack vector a lot. Having this feature would make matrix definitely more secure.
I imagine next to the buttons for "verify this user" an option to "pin this user's cryptographic identity" or "pin key" or something along those lines. (It can be smaller or further down, if that's considered better UI.) This would result in a signature like when using cross-signing but annotated with a flag, that it's an unverified signature and the date. So the meaning of the signature is "I have seen this key, supposedly from this user id, at this date".
From this moment the following changes:
- The user shield will turn another color e.g. blue.
- If a room contains no black or red shield users, but a blue shield user, it will appear with a blue shield.
- Seeing a not cross-signed device would have the same effect as for a verified user.
- The user info panel of the user would show "key pinned since
<date>". - The verify button would still be present and work as normal, but verifying a key while you have pinned another key should raise a loud warning. A successful verification replaces the former "pinning signature".
That's it.
There are three additions thinkable:
- This could be hidden completely behind a feature flag in the options.
- There could/should be a personal option per room to "pin all users that join this room".
- There could/should be a per account of "pin all users in encrypted rooms (trust on first use)"
Something along these lines would be awesome!
Now, if there are ways people from the community can contribute to making this happen I‘d love to hear about that.
I just watched Matrix Live with the Element Roadmap. Thank you for the tour! I am really amazed by all the features you are planning and I realize that you have a lot of issues to think about and to prioritize.
Still I couldn‘t fail to notice, that this issue is not on the Roadmap. So I just wanted to try to bump this again on your radar. Although I feel a little bad about being nearly the only person bugging you about this. I am pretty sure that this is feature a lot of people (which know how E2E works) would really appreciate.
Hey @maralorn— thanks for keeping us honest on the roadmap! I've added this to the the inbox for us to figure out how to to prioritise.
The rest of your proposal looks well thought out all round and is really useful to help aid critical thinking. You hit the nail on the head describing the crux of the bottleneck here:
Sadly for this issue I wouldn‘t know where to start. This needs UX, design, spec, client and (maybe) server considerations and is not a very small effort in general.
In practise, we need to focus cross-functional efforts across all of these disciplines, along with bounds of user research, testing and iteration to ensure:
- Any complex, security related features actually make sense to users— e.g. terms like 'pin this user's cryptographic identity' is triggering alarm bells and finding something which works requires lots of research, testing, observing and iteration
- They also make sense holistically throughout the entire app and are conductive to building a mental model of what's going on
We're in the midst of figuring out how/if/when we can resource a cross-functional team of people to work encryption stability & user experience. I can't promise any timelines at the moment but issues like this will be prime targets for that group.
Edit: I should clarify— I wrote that comment very much wearing the hat of 'what would bottleneck us being able to merge into master, have everything on by default & execute on all platforms (web/desktop, iOS, Android)'. I'll defer to the folk closer to our encryption implementations but in principle there shouldn't be an issue with developing something for web behind a labs flag to experiment with.
Thank you for your answer!
I see the huge gap between exposing all users to this and trying this out in labs. It's certainly not trivial.
Having this behind a labs flag for years would completely scratch my itch and might just work for everyone who really cares about this. I would be very happy about that.
https://github.com/element-hq/element-meta/issues/764 tracks an implementation of MSC3834, which (I understand) would solve this issue.
We are currently working on a limited implementation of TOFU, as part of the "Invisible crypto" project; this project is tracked at https://github.com/element-hq/crypto-internal/issues/282 (unfortunately not a publicly visible issue, as it contains commercially-sensitive scheduling information). MSC4153 details the protocol-level changes here.
