Group Communication

[lgrahl]

Currently, the spec provides 1-to-1 client communication only. There might be use cases for group communication with a shared secret key or multiple responders communicating with an initiator.

[dbrgn]

Do you already have a concrete use case for this?

[lgrahl]

Nope. Just a wild idea so far. :)

[dbrgn]

Is WebRTC group communication something that's already being done?

[lgrahl]

For something like a video conversation, you will have to establish a peer-to-peer connection to every other participant (or use a server that bundles the streams, but that would basically be MITM as a service). SaltyRTC is a little bit painful for that at the moment as you will have to create n WebSocket connections with TLS, the full handshake, etc. This is where group communication would kick in.

I have a broad concept in my head where the participants have to exchange a secret key beforehand. They'd use the secret key for authentication towards the server and then ephemeral key pairs would be established as for 1-to-1 communication. The difference is that there's no initiator/responder relationship but everyone can communicate with everyone else on a path.

[dbrgn]

I think that's definitely something for a future version, not something we should worry about for the 1.0 version :) I think first we'd need some more real world users before adding more complexity.

[lgrahl]

I completely agree. (The only reason I've mentioned it in #112 is because I want to change the path slightly.)

[dbrgn]

But do we really need that in the path right now? All peers need to agree on the used path anyways, so they can just as well agree to use a new URL schema instead of the old one once we need it.

I think it would confuse people more than it helps if we already put the communication mode in the URL even if no other modes than 1to1 are supported.

[lgrahl]

I think you're forgetting the server here. The server needs to know which mode clients operate in. And a change later might be a lot harder than doing it now. Even now, we can only provide compatibility in case administrators update the server before the clients are updated (if we do it the way it's suggested in #84).

[lgrahl]

Here's my current idea (I'll update this posting from time to time).

Keys

Groups have a secret key all group members need to know. Removing group members will require changing the secret key of that group. Therefore, we should recommend that group keys are always short-term. However, key management will be entirely up to the application (as it currently is).

As in initiator/responder mode, group members will establish session keys with one another.

Path

Groups will use /group/<hash of secret key>. What hash is and whether that's secure still needs to be discussed.

Client-to-Server

• No initiator/responder roles.
• There will be a new role member (meaning group member) which basically works like the responder role but uses an ephemeral key pair.
• Address designation will not change.
• 'client-hello' will always be used (thus we always establish ephemeral keys towards the server).
• 'server-auth' will contain a list of currently connected group members (in form of ids) in the members attribute.
• Group members will not be announced. Thus, 'new-initiator' and 'new-responder' will not be used. For this reason, path cleaning is not possible in group mode (at least not reliably).
• Possibility to use 'drop-responder' needs to be discussed. If we use it, we should probably use it as 'drop-member'.

Client-to-Client

• The server will allow communication between all group members.
• 'token' will not be used.
• 'key' and 'auth' messages will be encrypted by the secret key of the group.

Changes to Initiator/Responder mode

The path should be changed to /1to1/<public key of the initiator>. This doesn't break backwards compatibility as path validation can depend on the chosen WebSocket protocol. If v1 is detected, the path can be prepended with /1to1.

Protocol

The protocol version should probably be v2.saltyrtc.org. This breaks a little with semver because we're still compatible to v1... but we've established v1 in IANA, An alternative would be to use v1-1.saltyrtc.org but I think that's confusing.