Expire QR Codes

[Hocuri]

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

  The first attempt at prevent-online-leak [POSTPONED] Sketch (just TODO comments) for prevent-online-leak #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.

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

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. 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 SecureJoin: encrypt {vc,vg}-request message #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

[link2xt]

Bob should still show a one-directional verification if he already knows Alice's key.

We do not show one-directional verification anywhere. Contact.is_verified() still returns false if there is no backward verification. With #5116 we will however mark 1:1 chat as verified very early on.

[Hocuri]

Yes, I meant "get", I edited my original comment

[link2xt]

We need to pick an expiry time, we talked about something like 2 days. Thinking about it, I'd actually argue for something like 10 minutes, since that's enough to send a QR code via Signal if need be, but often not enough for Eve. If you want offline-verification, just scan the QR code in both ways.

This might be a problem if you want to setup contact via a friend using Signal or other messenger who you trust to resend QR code but nobody is online at the same time and Signal cannot be used as you don't want to share phone numbers directly. With chatmail this is a problem because you cannot even have forward verification and send a message. Scenario is constructed as chatmail is new, but I have seen this pattern of relaying Discord and similar messenger invitation links, SMS codes and so on.

Maybe "backward verification" (AUTH token) should expire in 10 minutes as it is important for verification security, but "forward verification" (INVITENUMBER token used to request the key) can take longer as it is just used to request the key and worst case leaks online presence. In any case we better talk about expiring these tokens rather than "expiring QR codes" which contain multiple tokens.

[link2xt]

Add context to securejoin invites

Currently if Alice shows "setup contact" QR code to two different Bobs while being offline, she will later get two chats from Bob 1 and Bob 2 without the ability to tell who is who.

One workaround is to create a group for each contact and use secure join protocol instead of setup contact. Then each Bob gets into his own group chat.

We can however change the core to show a new QR code each time QR code screen is displayed and associate some context such as the date and time to it (or allow to select custom name like "Cryptoparty" or "Onboarding Bob 4", but that would require UI changes). Then we can add this context as an info message to the chat (either 1:1 chat in case of setup contact or the group chat and 1:1 chat in case of securejoin). So unless Alice shows exactly the same QR code to multiple contacts, it is then possible to tell which Bob is the first one and which one is the second and add more context by actually writing messages into the chat. (based on short discussion with @r10s)

[Hocuri]

Is this meant to be for usability (preventing confusion amongst friends) or for security (preventing attacks)?

Is this meant as an alternative to expiring QR codes? Or as a future improvement we might do afterwards? Or something we should do independently of expiring them?

[link2xt]

I think adding a context is an alternative to "After securejoin completes, show a dialog asking the user to set a name for the contact." that can be implemented entirely in the core and without UI changes like a new dialog. We can also make it possible to set a context while showing a QR code, then user can see the context in the info message later and rename the contact accordingly.

[Hocuri]

Are there any user reports of users who onboard two friends with the same name at the same time and then can't tell them apart?

It seems unlikely to me that just the date and time is very helpful for most users.

And if we make it possible to set a context while showing a QR code, then it seems unlikely that many users will a) find this option and b) be so concerned that they won't be able to tell apart the two people they onboard next that they add some context. Plus, we will need to add some UI for this, too.

BTW, for "After securejoin completes, show a dialog asking the user to set a name for the contact." we can just reuse the edit-contact dialog, and we won't need any new API, which will make the UI implementation simpler.

[iequidoo]

One workaround is to create a group for each contact and use secure join protocol instead of setup contact. Then each Bob gets into his own group chat.

This can work, but Alice should take care to look at the original group name because Bob can rename it. So i think this workaround is too complicated for users.

EDIT: Maybe don't complicate the default QR code screen, but add "New Named Contact" next to "New Contact"?

[dkg]

Are there any user reports of users who onboard two friends with the same name at the same time and then can't tell them apart?

This is asked as a bit of an overstatement, but i have certainly onboarded more than one person while i was offline, and then received "green checkmark" contacts once i got back online where i couldn't tell who was who. People don't necessarily choose obvious names for themselves.

[dkg]

I think the usability concerns are real here, and i also think that mere expiration dates and visible date/time info are insufficient for real-world defenses against endpoint confusion/misattribution. So real usability work needs to be done here to think through a sensible workflow. The fact that my device has continued to show the exact same QR code for months means that if any one of my contacts decided that they wanted me to receive an ungovernable amount of spam, they could simply re-transmit my invite QR code to an arbitrary number of spamming lists.

Currently, it looks like Delta's semantics are "if i show you my QR code, i am allowing you to invite any arbitrary number of contacts to appear as verified contacts, with no way for me to distinguish between them." this is a surprising semantic.

[dkg]

I think what i would like for most individual introductions is a semantic more like a single-use invite:

• give this scrap of paper to someone, and then they (and only they) can use it to establish a channel back to you.

I think this covers the use-case for single introductions, and it seems plausible that those introductions could be associated with arbitrary stored internal metadata, so that when the contact does eventually come in, the user's own contextual notes are already associated with it.

I recognize that this proposal doesn't necessarily cover the use case of "i'd like everyone in this group to be able to contact me securely". I'd be curious to hear proposals for how to achieve such a semantic in a meaningful way for the user without any input from the other participants' devices. What info should i learn? what sort of temporal/spatial bounds should i associate with such a broad group invite?