Private communities like Slack or Discord (discuss more and break out tickets)

[holmesworcester]

Here we want to have a left sidebar that lets you create new isolated waggle networks with their own family of users, channels, private channels, and DMs that are isolated from each other in every way we can imagine.

We want to make it pretty much impossible for anyone outside a team to DoS a team, or for anyone to be able to infer who is in that team. We can use Tor encryption to protect the privacy of public channels. There are some proposals in the comments on how to do access control.

Removing users gets complicated, but the simplest version is probably to keep a list of all known users and their keys (necessary for orbitdb dm'ing) and to DM each user except the removed user a new key, signed by the admin.

As part of this, we should write up how Tor and Waggle work, for outside review, and circulate it on the tor list for feedback, and in the orbitdb / ipfs communities.

For the security requirements, have a look at the threat model and feedback. We should finalize the details of the threat model but the main pieces are there: https://forum.zcashcommunity.com/t/zbay-threat-model-request-for-feedback/38685?u=holmesworcester

Sidebar mockup:

[holmesworcester]

Here's a concrete first proposal. Given the assumption that the admin is honest and the invitee is online, this achieves a few important things:

1. At the moment they join, a user has a complete list of every member in the group with their identifying information (onion address, username, public keys, zcash address, etc)
2. Every online member has correct identifying information for every other online member.
3. Every user will sync information about new users as soon as they sync messages.

Here's how it would work:

1. Admin creates an onion address.
2. Admin sends onion address to invitee through some secure channel.
3. Invitee pastes onion address into app.
4. Invitee generates identifying information such as onion address, public keys, username, etc (like a certificate signing request)
5. Invitee connects to onion address and submits it.
6. Admin signs invitee's request and adds it to a "users" orbitdb. (in our first version this can happen without admin user intervention)
7. All online users (and eventually all users) receive the new, signed user information, and see a message like "[admin-name] added [invitee-name] to [community name]."
8. Admin provides the "users" orbitdb (in some form) directly to the invitee.
9. Now the user's relationship to the group is comparable to that of a typical offline user, and they connect as any user would.
10. Once they connect to their first peer, they send a "joined" message to other users, which displays as "[invitee-name] joined [community name]."
11. Either users include their admin-signed certificate with every message, or we hide a message from a user until you have synced with them, at which point you will have a version of the users orbitdb that includes them.
12. Users are not allowed to change their username or signature. If the app observes non-identical username/signature mappings it should show a full screen alert to the user, warning them of a malicious admin.

Once we release this system, we can make this system more secure and flexible progressively on a few different axes.

• catching malicious admins
• helping admins recover their accounts
• removing the requirement that teams have a secure channel for invitations. e.g. if the team name is pinned in the app, the user can check the signature to see a human readable team name, to confirm that the invitation link they are receiving is authentic and not the result of a man-in-the-middle attack. (Teams can pin their names in the app, just as browsers pin the HSTS preload list, and teams can review the list to ensure there aren't phishing/spoofing attacks using similar names.) Alternately, the team could "pin" an invite URL in the app, though this invites spam requests or DoS.
• removing the requirement that inviter and admin be simultaneously online, e.g. by creating an "unconfirmed" status for new users and letting the admin confirm their username when the admin is next online.
• allowing these usernames to be used globally across channels. E.g. if the public keys for admins are in the app, along with an organization name, that can serve as a "domain name" for every user registered there. And other groups can accept users' certificates, which in turn opens up simpler and more secure options for user registration since you can now invite users "in band". This also lets people use the same identity across groups.

[holmesworcester]

A less strict version would be:

1. admin sends invitee their permanent onion address, out-of-band, at which point user can see messages, discover / connect to other peers, sync the "users" orbitdb, and add all addresses to its list of peers.
2. invitee sends a signed join request with their information in a DM to the admin. until the admin acts on this request, their messages are ignored until they are added, and all messages except the users orbitdb are encrypted with a key they don't know. (they are part of the community's libp2p network, but they have no meaningful access yet.)
3. admin adds this information to the "users" db, which only the admin can write to, using orbitdb access control and DMs the invitee the key to decrypt all public messages. "[invitee-name] joined [community-name]" displays in public channels, so that everyone knows they now have access.

[holmesworcester]

Another proposal is:

1. create a tracker onion service
2. all users connect to the tracker and join a global libp2p network
3. all users register a username and their public keys with a centralized onion service.
4. all online users already in a community share their peer ID encrypted, under the community identifier on the global dht.
5. admin communicates their own username to invitee, or invitee communicates their username to admin, out of band through a secure channel.
6. admin adds invitee username and public keys from global identity server to the community's 'users' orbitdb.
7. admin sends a global DM to the invitee with community identifier to retrieve encrypted peer addresses from the dht, and the key to decrypt them.
8. invitee retrieves peers from the dht, and joins the network
9. invitee retrieves 'users' orbitdb. (or possibly there's no need to if we just use global usernames.)

Advantages over above approaches:

• the invitee does not need to be online at the same time as the admin, because global DMs are stored by other peers.
• if there are many users in a community, it will be easier for returning users to discover peers that are online, because they can use the dht instead of trying all onion addresses.

Disadvantages over above approaches:

• It leaks information about who is in what group to the global, unless/until we use tor to conceal this.
• It trusts privacy to the centralized username registration server, because it can impersonate invitees, receive an invitation, and join the group, at least for long enough to retrieve all stored messages before the intended invitee (who did not receive an invite) alerts the admin.
• It introduces a reliance on three new adversary classes that we (and users evaluating the security of this) would have to reason about: the tracker, the centralized registration service, and peers in the global DHT.

We can pin the public keys for community names (admins) in the app so that an invitee is not trusting a central server to contact the correct admin. But the admin would still trusting the central registration service to decide who they let in, unless they verify keys out of band.

If the admin can confirm out-of-band that the intended invitee joined, they know there was not a MITM. It would still be possible for the centralized registry to impersonate an invitee, receive an invitation, and retrieve group messages, so this still trusts the privacy of the group to the centralized registry.

[kowalski]

Few comments

Creation of community:

• Owner (creator) of the community generates the Root CA for this community. Additionally he uses the Root CA to generate a User Certificate for himself - becomes the first user.
• If Creator wants to appoint Admin who has power of inviting users to community, this is done by generating Intermediate CAs for each Admin. Consequently Admin also has two certificate: User Certificate for proving his own identity and Intermediate CA certificate for singing User Certificates of other users.

Kicking a member out:

• When we want to throw the member out of community we add his userCertificate id to CRL list and save it to user registry.
• All users from this point forward will not accept a peer connection from this user.

Process of inviting user:

• Owner/Admin starts a specific hidden service for invites. Sends it using other channel (like email) to user he wants to invite.
• Invitation should also include some short-lived token, that will make it expire and not possible to re-use maliciously in future.
• Invitee connects to this service and sends it CSR (certificate signing request). Owner/Admin checks if CSR is acceptable (is requested nickname free). I think we could also put in certificate: first and last name, onion address that the user will use in this community. But we don't need to include this if we don't want to (to decide)
• If CSR is accepted invitee receives back the certificate and the list of (at least 1) onion address(es) it can connect to join the community.
• Owner/Admin saves the newly generates certificate to orbitdb structure.

Registry of users:

• I think for this structure we should use "log" not "keyvalue". Every community user parses this list in order and only considers correct certificates.
• This structure also holds information about certificates being removed (updated CRL files).
• We don't rely on OrbitDBs ACK here. Valid entries will be signed by appropriate users' private keys.

Validation of user certificate:

• Validation of certificate will happen in WebsocketOverTor (https://github.com/ZbayApp/waggle/blob/master/src/libp2p/websocketOverTor.ts).
• Connecting party should put CMS (in the header of handshake request when establishing websocket connection)
• Receiving party should check if certificate chain is valid and resolves to Root CA and if the certificate presented is not revoked (on CRL list) or expired
• If CMS checks out, connection is accepted and receiving party presents his own CMS.
• Connecting party validates the CMS and drops connection if it's invalid.

Signing individual messages:

• We should not put entire certificate chain with every single message, as this would be excessive. Instead we should just put signature (like we used it) and pubkey. Pubkey has not been historically included because we were using crypto library that was capable of extracting pubkey from signature and signed data. To my knowledge pki.js doesn't have a method for this, so we should just add pubkey.

[kowalski]

Note from discussion:

• Zbay level message format needs to have some nonce field to prevent replay attacks