# Verifiable Room Membership based on token distribution

This proposal is an attempt to provide a way for members of an encrypted room to detect and prevent a malicious homeserver to inject members in a room. Ensuring that keys will never be distributed to such injected users.

This proposal is oriented in a way to make implementation as simple as possible, and also avoiding the need to issue new user keys that would need 4S updates or new secret distributions. It should limit the number of client side state resolution/validation needed.

The main limitation that make the simplification possible is achieved by considering that every membership change **must be initiated by a validated member** (i.e explicit user action) of the room (PL to send state).
I.e in order to join:
* A user must be invited by a verified user
* A user must request membership that would be validated by a verified member (knocking)

This means that verifiable membership will not be possible in public e2ee rooms. This is probably fine as per nature any one could join.

The design of this verifiable membership protocol **relies on the availability of a secure peer-to-peer channel** for the exchange of secrets between members (olm channel).

### High Level Group fingerpring key idea

The system is based on the fact that members of the rooms should all share a common secret (ed25519). This secret is used to sign `join` (or a new `verified_join`) events. All members can then simply validate the membership of a new member by checking the signature of the `join` event ensuring that the new user has the correct secret.

**Initial key creation**: The group fingerpring key (GFK) is randomly generated by the room creator.

**Key distribution**: The member initiating the membership change is responsible of distributing the GFK to the new member via a peer to peer olm channel (typically on invite).

**Sending Proof of memberhip**: The proof of membership is achieved by signing `join` events content with the current GFK. As state events are not encrypted, they should also be signed by the event author MSK (allowing to validate event -> mxId link).

**Re-keying**: GFK should be rotated when a user is kicked/ban, the member performing the action should then distribute the new GFK to the current verified members, and send a auth update state event for existing members signed with the new GFK (and his MSK)

Problem of user leaving (/part):
The user parting might not have enough power level to send state events, so can't initiate a re-keying.
Mitigation: The next time a potential validated admin (enough PL to send state) user sends a message (or opens his session, but race pbs?) he would see that the GFK was shared with two many users, and then re-key, distribute and send back auth update state events.
So technically there is a window in which a volountary leaving user, colluding with a malicous homeserver to re join the room that would have a valid proof from the current group GFK. This until an admin (enough PL) member syncs and detect the part event.

**Checking Proof of memberhip**:
Clients maintains a set of validated members in the room, and only distribute megolm keys to them (regular rules of device verification applies)
1) On membership change:
- join: The client checks the `join` event or the latest auth update state (re-key) and mark the user as validated if signature matches;
- leave: Remove the user form list of validated members (might check event signature too?)
- auth update: revalidate affected memberships

2) On GFK update (via olm Channel) => Trigger a validation check of all members

3) On cross signing key reset of a member => Trigger a validation check of all members

### Properties / Mitigation

**Resist to MSK rotation**:
If a user resets is MSK, he should re-issue a `join`event signed with both current MSK/GFK.
Notice that as per current rules, the user that rotated his keys would become unverified for other users, and thus megolm room_key would be withheld by senders (if proper setting used). So it would be an unverified validated member, and will properly be able to decrypt after verifying with existing members.

**Join Rule Changes**:
For simplification purpose, the change of join rule change in an existing verifiable room should block sending client side (as we do now when encryption is reverted). The initiator of the join rule change should tombstone the existing room and migrate to a new room.
The implication is that we introduce a new join rule (validated_invite), different that the existing invite rule.

**Verifiable membership in restricted room**:
We need to introduce a new knock restricted rule. The knocking is needed to have a validated member initiating the GFK distribution.

**Power level privilege escalation**:
Would mean that an actual verified member of the room (owning the current GFK) colludes with a malicious home server to share the GFK an issue invites for intruders. Notice that any how as trusted member he could leak the conversation by screenshots anyhow.
This is a bit orthogonal to the current MSC, but clients could if they want validate Power Levels (given that we extend state event signing by MSK) and thus block sending complitly in such rooms.

**3pid invites**:
TODO