- Why send the cookie all the time? It's known after the initial message towards the other peer.
- Make sending application data more efficient (v1 requires embedding data into a msgpack object).
- Allow chunking of data (designed for but not limited to application data).
- Design application data to not suffer from head-of-line blocking by using a stream identifier along with chunking.
- Unsolved so far: This requires a flow control that is carefully designed to prevent filling its send buffer too much. It may even require its own acknowledgement protocol in order to do so.
- Allow group communication of up to 65534 participants.
- Get rid of the initiator and responder role.
- Spec: This is not only a signalling protocol. It's also a way to exchange arbitrary data over an end-to-end encrypted transport.
- Spec: Do we want to separate SaltyRTC WebSocket Transport and SaltyRTC Protocol?
- Spec: Do we want to replace MessagePack with FlatBuffers or the like?
- Feature: Do we want task chaining?
- Speed: Do we want (optional) 0-RTT support? Ideally, this would skip all client-to-server and all client-to-client messages (at least for 1-to-1 communication) and there would be only one RTT for the client's 'auth' messages. It could be done by negotiating a session id for both server and client.
- Speed: RTT implications of sending two messages after another from the same source. Should these be avoided?
- Speed: Chunk-then-encrypt, rather than encrypt-then-chunk?
- Speed: Use little endian instead of big endian?
- Security: Implications of having a secret key in a QR code instead of
public key || token
. - Security: DoS protection is gone as path cleaning isn't possible anymore
- Security: Can we encrypt the header as well?
- Instead of cookie being an optional part of the header, 'server-hello' and 'client-hello' could contain a cookie field and before 'key' there could be an unencrypted 'cookie' message. Depends on the outcome of RTT implications of sending two messages after another from the same source.
- Should we keep the
3xxx
range of close codes or go for the4xxx
range? If we stay at3xxx
, we need to register our close codes at the IANA WebSocket Protocol Registries
- Use (the original or the IETF variant of) the AEAD ChaCha20-Poly1305 construction or libsodium's AEAD XChaCha20-Poly1305 construction. This allows us to have additional authenticated data that does not need to be part of the nonce, nor does it need to be encrypted.
- Clients use a shared permanent secret key (which is an implicit token) instead of permanent public/private key pairs.
- Clients use an ephemeral key pair towards the server.
The path is a hash of the permanent secret key.
-
Flags:
- C: Cookie included (between sequence number and data)
- E: End-of-message (message is now complete)
- A: Application data
-
Stream is the stream identifier (for application data but could also be used for parallel tasks)
-
First 8 bytes are additionally authenticated data with AEAD cipher
-
Nonce :=
Sequence Number || Cookie
.0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|E|A|R|R|R|R|R| DUNNO | Stream | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Cookie | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Set the cookie field in the header for 'server-hello' and 'client-hello'
- Always use 'client-hello'.
- List of connected clients in 'server-auth'
- 'new-client' announces that a new client is connected
- 'new-initiator', 'new-responder' and 'drop-responder' are gone
- For 'send-error', split the fields id into source, destination and sequence_number
- Set the cookie field in the header for the 'key' message
- Clients send the 'key' message directly (async) which is encrypted by the shared permanent secret key.
- The client with the lower assigned identity is called the controlling client, the other one the controlled client.
- 'auth' is sent with the tasks field by the controlled client first, then 'auth' is sent with the task field by the controlling client.
- 'token' message is gone
Just another idea: Deposit a last will in terms of generic encrypted data (encrypted by which keys needs to be discussed). This could be useful for various tasks in case two peers aren't permanently online.
@dbrgn: For example, in case Threema Web allows caching messages in the future (to drop the permanently connected requirement), the cached messages (as a result of currently not being connected to the app) can be deposited as the tasks last will on the signalling path. This prevents messages from being lost when there's no connection to the app but the user is closing the browser. The app would pick up the deposited message as soon as it wakes up from the push notification and send it.