Securejoin v3: Encrypt all securejoin messages

[Hocuri]

As explained at #7042 (comment), we would like to change the securejoin protocol. Most importantly, all securejoin messages will be encrypted.

Securejoin is the protocol than runs when the user scans a QR code or clicks on an invite link. By convention, the person who creates the QR codes is called "Alice", and the person who scans it is called "Bob".

Motivation

• Today, the first securejoin message (vc-request) is unencrypted. This leaks Bob's cryptographic identity.
• Also, the fact that some securejoin messages are unencrypted means that we need an exception in chatmail servers, which otherwise don't allow any unencrypted messages. It also makes workarounds like Detect Secure-Join request step using only Secure-Join-Invitenumber #7687 necessary.
• Today, there are two tokens in the QR code, AUTH and INVITENUMBER. Once everyone upgrades, we can get rid of the INVITENUMBER, making QR codes a little bit smaller.

Protocol flow chart

Old protocol	New protocol

If Bob already knows Alice's pubkey, there is a shortcut: The first two messages can be skipped.

Implementation considerations

• When Alice answers the first message, she doesn't know anything about Bob, not even his pubkey. So, she can't create a contact for him; but we can create and send the answer message pretty much directly, without using all of the existing sending logic that expects a contact id. I.e. we can directly create a MimeFactory or a RenderedEmail.
• Probably it's easiest to call the 3rd message vc-request-with-auth for backwards compatibility, even though this doesn't exactly describe what it does

Backwards compatibility

• In order to stay backwards compatible, QR codes will get a new parameter &v=3. This means that old clients will continue to understand them. Unfortunately, it also means that we need to include an INVITENUMBER, even though it's only needed if an old client scans the QR code.
• For the case that Alice or Bob has two devices, one of which understands the new protocol, and one of which doesn't:
  • What's easy to solve is the case that the old device created or scanned the QR code; in this case, we just need to make sure that we continue to understand these messages in observe_securejoin_on_other_device().
  • If the new device created or scanned the QR code:
    • The old device won't be able to decrypt the first two messages, because they are symmetrically encrypted.
    • Therefore, we need to make sure not to self-send the first two messages.
    • Apart from that, observe_securejoin_on_other_device() should understand the request-with-auth or member-added/contact-confirm message just fine.

[Simon-Laux]

• I assume vc-request-with-pubkey is encrypted to alice's pub key. (this is not specified in the diagram)
• I believe that Alice does not need to create a dummy contact for bob, she could just auto-reply to the vc-request if the provided AUTH token is still valid.
  • This would also make the first half of the handshake fully independent from the later steps, so in the future we could make new longer links that contain the full pubkey and those links could then start the process directly at vc-request-with-pubkey.

I think AUTH token is needed in vc-request-with-pubkey to identify the qr code it came from and what group the user should be added to. For me it is a bit unclear if the "maybe" is about not having AUTH token at all or just about the choice between AUTH token or just a hash or the AUTH token.

After some time we could not only remove the invite code but also the group-id/x the from the qr code and just use the AUTH token to remember which group it is for, further saving space.

my attempt at converting the sequence diagram to mermaid (as far as I understood it, could contain mistakes)

sequenceDiagram
    Alice-->>Bob: QR [Alice FP] [AUTH-Token]
    Bob->>Alice: vc-request
    Note over Alice,Bob: EncryptedWith: [AUTH-Token] <br/> Data: [AUTH-Token]
    Alice->>Bob: vc-pubkey-required
    Note over Alice,Bob: EncryptedWith: [AUTH-Token] <br/> Data: [Alice PubKey]
    Bob->>Alice: vc-request-with-pubkey
    Note over Alice,Bob: EncryptedTo: [Alice PubKey] <br/> Data: [Bob PubKey] [Bob Profile] [AUTH-Token]
    Alice->>Bob: member-added/confirm
    Note over Alice,Bob: EncryptedTo: [Bob PubKey] <br/> Data:<br/> Normal "adding to group/broadcast list"-message, <br/> which also contains [Alice Profile] 

Loading

[iequidoo]

I think AUTH token is needed in vc-request-with-pubkey to identify the qr code it came from and what group the user should be added to. For me it is a bit unclear if the "maybe" is about not having AUTH token at all or just about the choice between AUTH token or just a hash or the AUTH token.

AUTH (or its hash) is also needed to prove that you have the invite token, otherwise anyone knowing Alice's key could send the request. But yes, it's also sufficient for QR identification.

Overall the described scheme looks as two separate protocols: the first two steps are some "request pubkey" protocol and the second two are actually "secure join".

AFAIR, it was already discussed why we don't want Bob to generate a temporary keypair and this way shorten the protocol to 3 steps (in the 3rd step Bob should send his actual pubkey and profile), but probably because then Alice loses ability to review Bob's request before adding him to the chat (and sending a secret in case of broadcast).

[Hocuri]

Oops, there already is an issue, #7396, I'll merge the two