Element-web: TOFU in E2EE

[ara4n]

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

[nadonomy]

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.

[ara4n]

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

[maralorn]

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.

[maralorn]

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.

[ghost]

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