Specify scope of header parts about saltyrtc-meta

[lgrahl]

Outgoing and incoming Combined Sequence Numbers (CSNs) reside in the peer scope.

I've started creating a table for this but it seems really complicated when writing it down which part of the nonce resides in which scope for incoming and outgoing messages. I have the feeling that this is starting to be a weakness of the protocol or its just a matter of proper representation of the scopes. So far, I don't know.

This was my work so far (completely unfinished and I have the feeling its not representing the scopes in a satisfactory manner). Any ideas?

Header/Nonce Scopes

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Cookie                             |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Source     |  Destination  |        Overflow Number        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Overflow Number and Sequence Number will be called Combined Sequence Number.

Globally

Nothing

Session

• Cookie [out]
• Source [out]
• Destination [in]

Peer (each client or the server)

• Cookie (in)
• Source (with the exception that the server will use 0x00 for non-authenticated new clients)
• Overflow Number and Sequence Number (also called Combined Sequence Number)

[dbrgn]

Can't we just word it similar to this?

Per Session

• Each peer generates a Cookie
• The server or initiator self-assign the Address according to the spec
• Each responder get assigned the Address from the server

Per communication channel between two peers

• Each peer initially generates a Combined Sequence Number for every communication channel (SaltyRTC p2p connection or WebRTC data channel)

---

Not sure if that's clearer. But it avoids the terminology of scopes.

[dbrgn]

What's missing here: Data channels. Two parallel data channels use the same peerconnection between the same two peers. Should they share the CSN? (I can't really see why not.)

[lgrahl]

No, they have separate CSNs. In essence, a different CSN is being used for each channel (of each peer of each session). That way we can rule out replay attacks and channel instances do not need to share a number which may lead to race conditions for threaded clients.

(We really have to put our heads together and sort this out. Maybe an image would help.)

[dbrgn]

Is there something missing in the listing above? Is it correct?

[dbrgn]

I started implementing nonce validation, but stumbled over a problem. If we have to keep separate CSNs for server, initiator and all responders for both channels (websocket or datachannel) during signaling, the code gets really complex.

My suggestion:

• During signaling, each peer initially generates a Combined Sequence Number for every other peer
• Each wrapped data channel gets its own CSN

This way, wrapped data channels don't have synchronization problems over a shared CSN, but signaling can be simplified by having a single CSN per peer connection, no matter which communication channel they use.

[lgrahl]

IIRC you are saying that CSNs of the signalling channel should be reused after handover? I guess we could do that but the fields source address and destination address still need to be changed to the (negotiated) data channel id. I mean, we haven't really defined the header for data channels, yet. Here is my plan for both handover and wrapped data channels:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                          Cookie 2                             |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Data Channel ID        |        Overflow Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So, if this is the nonce/header before the handover...

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                           Cookie 1                            |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     0x01      |     0x02      |              0x01             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             0x7f                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then this would be the nonce/header after the handover (assuming that id 0 has been negotiated for the signalling channel):

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                          Cookie 2                             |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |             0x00              |              0x01             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             0x7f                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In addition, the cookie MUST be changed for wrapped data channels (that includes handed over signalling channels). Otherwise, nonce reuse is possible.
An alternative would be to change the key once again for data channels. Let's figure out what makes more sense or what is less error prone to implement.

[lgrahl]

Cookie scope has been quite a headache but I think I've figured it out:

• For clients, the cookie is randomly generated once and then valid for the entire session (connection to the signalling server) of that specific path.
• For servers, the cookie has to be randomly generated for each connected client and is then valid until the client disconnects.

[lgrahl]

@dbrgn Really sorry, but we have to change that again: The cookie MUST be random per peer, exactly as the CSN. After 'new-initiator' and 'new-responder', the client has to remove all previous information of the announced id, such as a cached cookie and CSN for outgoing and incoming data. Otherwise, it's hello nonce reuse.