Move group-id X from vg-request to step vg-request-with-auth

[r10s]

Step 2 of the "Out-of-band verified groups"-protocol reads as follows ...

in step 2 Bob manually confirms he wants to join the group X.
before his device sends the vg-request-X message.

... where the X is a placeholder for the group name and/or id, imu.

During implementation, I found it more useful to move X to step 4b / vg-request-with-auth. Reasons:

• the inviter side gets X when it really needs it in step 6 then - otherwise, the inviter has to track which X is used in which secure join
• X is not needed by the inviter in the response to step 2
• vg-request may not be sent when taking the shortcut in 2a; so we have to add it to 4b anyway
• the group id gets encrypted (in step 2 it would be sent unencrypted)
• finally, elegance: in vg-request-with-auth already the other parameters are send :)

[azul]

Hi @r10s ,

I don't have any objections against that change. However moving the -X into the encrypted part is not going to help much because it's also send in step 1:

in step 1 the oob-transferred type is TYPE=vg-invite-X indicating Alice's offer of letting Bob join group X.

We need this if we want Bobs device to display which group he was invited to. Otherwise we could just say: "Alice invited you to a group" We could then move the -X from step 1 into step 3.

In step 4 we could display the group name to Bob... - but that would require two user interactions. Or we could postpone the user interaction to step 4 - which would lead to a 'silent sms' scenario.

I don't see an ideal solution for this. Looks like we need to decide between different tradeoffs:

• hide group name from eavesdropper
• single user interaction
• prevent silent sms scenario

I think we can only have two of the three.

[r10s]

Hi @azul

I don't have any objections against that change. However moving the -X into the encrypted part is not going to help much because it's also send in step 1 [...]

Not sure, if we're talking about the same thing; maybe i have missed an important point about the -X :)

imu, ...

• in step 1 the -X it is sent out-of-band from Alice to Bob. In the Delta-implementation, the -X is the given group name plus an internal ~64 bit random group ID (already used for other purposes)
• In step 2 (before switching to 2a or 2b), the Delta-implementation ask if Bob wants to join group -X
• if Bob wants to join the group, we continue with 2a or 2b and sooner or later we're at step 4b
• at 4b, Bob sends the -X encrypted to Alice so that the correct vg-member-added can be done by Alice

I don't see an ideal solution for this. Looks like we need to decide between different tradeoffs:

• hide group name from eavesdropper: I think, the -X resp. group name/id is hidden from eavesdropper the way described above - sent out-of-band first at 1, and encrypted at 4b - however, this is only a side-effect (the other points are in the original message)
• prevent silent sms scenario: Bob's user-interactions are in step 2 (before switching to 2a or 2b) before any message is sent.
• single user interaction: Bob's user-interactions are in step 2 is Bob's only user interaction. Alice's user interaction is showing the QR code

btw. up to 4b, there is no big difference in the Delta-implementations between the "Setup Verified Contact" and the "Verified Groups" protocol - mainly in the question prompted to the user "Do you want to setup a verified connection with Alice?" vs. "Do you want to join the group ?"

does not use -X but does the normal handshake until step 4b where the -X can be sent encrypted.

(however, the suggested change is not mainly to hide the -X, this is only a side-effect)

[hpk42]

hey @r10s -- could you do a PR to implement your change?

[r10s]

@hpk42 i do

[azul]

Okay... we already moved on from this introducing the metadata in the boostrap code.
I checked we still fulfill the desired property that this issue was addressing.
We do not leak the group name publicly:
Verified contact and verified group data on the wires is the same up to step 4 and from there on all messages are encrypted and the keys have been verified.