- 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
I've considered replacing MessagePack with Cap'n Proto but dropped the thought. Here is why:
Pros:
Cons:
@dbrgn: Comments on that welcome.