Non-interactive E2EE Account Verification

[kevincox]

It would be very valuable to have a way to verify accounts non-interactively. For example being able to link to a Matrix account while also including a key fingerprint.

Use Cases

Starting a chat with "Public" account info

A trusted contact shares a link to a friends profile. It would be great if that could be automatically verified.

Right now if someone shares a link like matrix:u/me%3Ahomeserver.example By default I will fetch the profile from the homeservers and that makes me vulnerable to a MITM attack. If my trusted friend is sharing the link over a trusted channel it would be great if this could be avoided. For example sharing matrix:u/me%3Ahomeserver.example?fp=abc123 where fp is a fingerprint of an account key. This way the account can be verified automatically.

For example I am experiencing this in real-life. I had an in-person verification with my Mother. However my Dad didn't have a Matrix account at that time. My Dad has since gotten an account but I will not see him in person for a period of time. It would be great if my Mom could verify his account, then send me a link with the verification info that I could use to verify my Dad.

This is also very common when talking to semi-known people. For example I have many times shared my contact info in discussions in open source projects. Right now in order to add me as a contact they need to trust 1. the discussion platform (to make sure that the account URL is not modified) 2. my homeserver (to send them the right key) 3. their homeserver (to properly relay it). If some non-interactive verification information was included in this link they would only need to trust 1. As another example look at https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix. This file contains many Matrix IDs. It would be far more secure if it included fingerprints.

TOFU

Another way this could be managed is setting up TOFU. Right now if you don't interactively verify an account you can't take advantage of cross-signing and other benefits. This basically requires allowing "send encrypted messages to unverified sessions" as any new device added (even if cross-signed) will not be trusted. Sending to unverified sessions is a major security hole though as homeservers between you and the target can add new sessions at any time and you likely won't notice (depending on your client). Being able to pin the current account keys, or the account keys at the time of interacting with a new account could mitigate the risk of MITM attacks in the future.

Current State

Right now the current state for adding someone has some major downsides. With a trusted communication channel it isn't too bad. You can find a time and do an interactive verification. However this is still time consuming and so is often skipped. (I've verified maybe 5 people in my life, but regularly interact with dozens).

Without a trusted communication channel it is even worse. The other account will not be verified which means that you basically need to allow sending messages to unverified sessions. This opens up the possibility of MITM attacks from either your or the remote parties homeservers. Not only during initial setup but also at any point in the future.

Element Web does have the option to manually verify individual sessions based on the fingerprint but this doesn't appear to hook into the cross-signing infrastructure. So verifying any session will not verify cross-signed sessions or any future sessions.

Concerns

The major concern that I see is that this level of verification can be less than may be expected by interactive verification. For example if you go to my website and click on the "Contact me via Matrix" link you are trusting that there was no MITM, either by a rogue CA or the site itself. You may also get a fingerprint from someone who isn't fully trusted. For example if you are talking in a support room and someone says "John is an expert on that, send him the full logs and he will take a look". Having a fingerprint for John is certainly better than not having one but you can only really be sure that you are talking to the person that the sender wants you to talk to, not that it is actually the John associated with the project.

While this is all technically better than the likely situation today of having no verification it opens up the desire for recording level-of-trust. This opens an area of complexity that has so far been avoided. For example I may want to mark John as "Unknown Trust" but my Mom who I verified in person "Ultimately Trusted". But this doesn't really affect the protocol, it is more of a personal note. So that for example if I decide I want to donate money to John or give him a login to my server to investigate maybe I will try harder to verify that he is really the John from the project. Having a note that he is "Unknown Trust" may be helpful if I don't remember how I added this account 3 years ago.

What is Needed

I'm not 100% sure. At least we would need to standardize a URL parameter and format for the fingerprint. This way these URLs can be published in a way that is compatible with all clients. There may also need to be changes to the way that trust is recorded, but I haven't looked into this part of the spec yet.

Summary

While interactive verification provides a strong level of security its difficulty results in it using less often. Having a very easy way to verify accounts (for example transparently embedded in profile links) can greatly improve security in the average case without removing the ability to provide ultimate security via interactive verification.

Related MSCs / Issues

• Support transitive trust for E2E verification between users (i.e. web-of-trust) in some situations #433 (Another way to handle sharing accounts to another user with verification)
• Decentralised user accounts #246 (Sharing keys is very important if that is effectively the account ID)
• Decentralised identity (SPEC-458) #203 (Sharing keys is very important if that is effectively the account ID)