Trust design: perhaps an invite link shouldn't always be trusted (maybe it's a good idea to ask the user?)

ell1e · October 3, 2024, 1:07pm

I joined a group chat via somebody’s invite link, but I got this invite link through an extremely insecure connection. Now this person and everybody they know shows up as verified. But the link could have been tampered with in infinite ways or have come from anybody impersonating the person I merely hoped it is, and I wouldn’t know. Therefore I’m quite unsure what the “verified” could even possibly mean or guarantee in that situation.

My apologies if I’m just missing something, but there seems to be the assumption that if I got the link somehow that it was through a verified channel. Maybe one way to solve that would be after clicking or entering the link, Delta Chat could ask me if I got the link through an encrypted and verified source and I want to trust it. Sorry if I’m just being confused about this one and missing something.

ell1e · October 4, 2024, 11:22am

That reminds me, how can I get some sort of room ID to share in an untrusted way? E.g. for a mailing list where I know it won’t be securely forwarded, or when I post on some web forum where people won’t know me anyway so there’s perhaps no real meaning to a trusted invite link there. It would be nice if I could share an explicitly not trusted link in that case, but I only found this here which doesn’t seem to offer doing so:

I didn’t find any other obvious way to get a shareable room id that isn’t a trusted invite link. Is there one in the desktop client?

Raiden · October 4, 2024, 3:37pm

I think it’s best to have different profiles for different areas of your life.
For example, one profile for friends, family and people you trust the most, one for colleagues and another as a “public” profile for public groups. DC has a good profile switcher that makes it very easy to switch between these profiles. You can also create new chatmail accounts very quickly and anonymously.

ell1e · October 4, 2024, 4:25pm

Shouldn’t such profile use be independent of where I got an invite link? It seems useful but not necessarily relevant. (Sorry if I misunderstood.)

Raiden · October 4, 2024, 8:25pm

The invite links are simply used to establish an encrypted chat.
If you want maximum security, you have to meet your contacts in person to scan the QR codes. This is the only way you can be sure that the right person is behind a name. Everything else is inevitably less secure. But even then, you can never be 100% sure that someone else might have access to your contact’s device. This is the case with every messenger.

ell1e · October 4, 2024, 8:42pm

Thanks for your input, you seem to be possibly agreeing with my assessment then. Sadly, Delta Chat the app doesn’t seem to. That is why I hope there can be a user prompt about a link’s trust to handle this, rather than the app treating it as maximum trusted always.

ell1e · October 12, 2024, 10:52pm

Would it help if I suggested a UI design? Last time the devs seemed to hate my concrete UI suggestion though, which was fair in retrospect so perhaps somebody already has a cool idea that would beat mine on how to solve asking the user about how much a link should be trusted.

link2xt · October 13, 2024, 4:49pm

There is a huge discussion of similar issues at GitHub:

github.com/deltachat/deltachat-core-rust

Expire QR Codes

opened 03:05PM - 22 Dec 23 UTC

Hocuri

verified-chats

## Context https://securejoin.readthedocs.io/en/latest/ explains the current …protocol and the considerations that led to it. Delta Chat doesn't actually implement expiry yet, which this issue is about. ## Motivation - prevent-online-leak <details> The first attempt at prevent-online-leak https://github.com/deltachat/deltachat-core-rust/pull/4932 turned out to be quite hard to get right usability-wise, esp. concerning groups: > This rises an UI question in case of someone trying to join the group using expired QR code. In Zoom users who are invited but not yet approved end up in some sort of lobby. If we open a new contact request when someone tries to join old group and ask to approve, user has no context to decide why they should approve the contact. Implementing approvals for joining the group is better, but would require UI changes on all platforms. </details> - Usable-security-wise, it will give green checkmarks a clear meaning without any exceptions (like, it's guaranteed that there is no MitM EXCEPT if you published your QR code on your website, or you shared a greencheckmarked-group-invite in a large group, or any of the people that are in greencheckmarked groups with you did one of these things) - Finally, this would bring us closer to the [securejoin spec](https://securejoin.readthedocs.io/en/latest/new.html#setup-contact-protocol). ## Details - Bob should still get a one-directional verification if he already knows Alice's key. - In order to warn Bob that the QR code is expired, we need to add a new parameter to the QR code. This is possible in a backwards-compatible way. - We need to pick a date when all the existing QR codes without an expiry expire. - QR codes for bots should not expire (if that's hard to do technically, set the expiry date to something very far in the future for them). - QR codes contain 2 tokens today: [INVITENUMBER and AUTH](https://securejoin.readthedocs.io/en/latest/new.html#setup-contact-protocol). When Alice receives the INVITENUMBER, she automatically replies with her public key. When Alice receives the AUTH (in an encrypted subsequent message), she marks Bob's public key as verified. We can select separate expiration intervals for them, e.g. 10 minutes or until for AUTH ## Problems 1. Group invites: An invite link to a g-e2ee group chat can not add the joiner device if the link expired. - _Solution 1_: simply not show the green checkmark as soon as someone's public key is not verified. I.e. to downgrade the group for some/many members in this case (@missytake), but not for the members who have everyone verified - _Solution 2_: Show a helpful error message: - Maybe "This QR code is expired. You can let Alice scan your QR code and then ask her her to add you to the group." with a button "Show my QR code" and "Other possibilities" where "Other possibilities" shows how Alice can clone the group to an opportunistic one - Or simply "This QR code is expired." 2. You can't encrypt after scanning a QR code with expired INVITENUMBER, which poses a problem with Chatmail -> INVITENUBMER needs to be valid for a rather long time (≥ a day). 3. We will have more cases where people accidentally have a verified group and now want to add someone they have not verified. 4. Technical challenges: - The QR code only contains the fingerprint, no key, so we can't directly mark the key as 1-way verified, but instead have to remember the fingerprint and then mark the key as verified as soon as we receive it. - If Bob scans a QR code with his phone and then doesn't open DC on his PC for a while, the QR codes might have already expired by the time he opens DC on his PC -> We need to make sure that the contact is verified on the PC too, in this case. ## Open Questions - Should we show a green checkmark for contacts with a verified public key who don't have us verified? (i.e. forward verified but not backwards verified) - Should we allow "opportunistic" key changes for contacts with a verified public key who don't have us verified? ## Alternatives - Fix problem 2 (see "Problems" above) by including a key in the QR code so that Bob can encrypt to Alice without having to wait for her answer. - Discussed at https://github.com/deltachat/deltachat-core-rust/issues/5182 - This brings us away from the SecureJoin protocol (OTOH, noone except us implements it, anyway). - Upsides: It makes the protocol run faster (2 instead of 4 messages), and all SecureJoin messages will be encrypted - Including the whole OpenPGP key will not work for v6/crypto-refresh, because we will eventually need to transmit two keys - _Possibility 1_: Create a ED25519 PGP key for each invite. The public key replaces the INVITENUMBER. Bob can use it to send AUTH encrypted in the first message already, and to encrypt messages before Alice answers with her actual PGP key. - Downside: Complexity. - _Possibility 2_: Put a passphrase for symmetric encryption into the QR code, which replaces AUTH. - Upside: Will not need adaptions for PQC. - We should still include the public key fingerprint in the QR code, so that the scanner can do a one-sided verification if AUTH is expired ## More possible improvements: Both these improvements would help with the usability problem brought up by @dkg that a verified-checkmark implies something about identity: - After securejoin completes, show a dialog asking the user to set a name for the contact. This way, the green checkmarks will mean something about identity because the user confirmed that this display name goes with the contact who just scanned the QR code. - This will require that we either let AUTH tokens expire as soon as the app is not in the foreground anymore, or that we show a notification receiving a vc-request-with-auth message if DC is in the background already. - Also, we need to figure out what to do for transitively verified contacts. WhatsApp shows all display names with a "~" until the user manually sets a name for this contact, and they show a prominent prompt to add a contact in the 1:1 chat) - Don't show green "verified" checkmarks, instead show a warning when messages are not guaranteed-end-to-end-encrypted, possibly in the message composition field, on the send button, and/or where the green checkmarks are today