Nonce Validation about saltyrtc-meta

[lgrahl]

The following things need to be validated on each incoming message:

Source byte

Only applicable to signaling nonces

• During server handshake:
  • Assert that source byte is 0x00 (server)
• During peer handshake:
  • Assert that source byte is 0x00 (server), or...
  • ...as initiator:
    • Assert that the source byte is in the range 0x02-0xff (responder)
  • ...as responder:
    • Assert that the source byte is 0x01 (initiator)

Looking good so far.

• After peer handshake:
  • Assert that the source byte is the peer address

I don't understand the difference between during peer handshake and after peer handshake. Could you elaborate?

Receiver byte

Only applicable to signaling nonces

• Before receiving the server-auth message:
  • Assert that the receiver byte is 0x00 (undefined)
• For the server-auth message:
  • Store the receiver byte as own address
• After an address has been assigned in the server-auth message:
  • As initiator:
    • Assert that the receiver byte is 0x01 (initiator)
  • As responder:
    • Assert that the receiver byte always corresponds to the own address

Correct!

CSN

• The CSN is stored separately per signaling receiver or secure data channel, as per #30 (comment)

Basically per endpoint, yeah.

• On first message:
  • The overflow number must be 0
  • Store the CSN

Additionally, SN SHALL also be random.

• On each subsequent message:
  • The CSN must be higher than the previous CSN

Cookie

• Assert that the server/peer cookie hasn't changed

Yes.

Open issues

• Is it enough to validate that the CSN is higher than before, or should we also check that the increase is within a predefined range?

Incremented by 1. Nothing else is acceptable as this is a reliable and ordered channel. Note, that we're assuming here that there is no message in between a client-to-client message that produces a 'send-error' and a following message. However, 'send-errors' are only recoverable during handover stages anyway.

Close the issue if there are no further questions. :)

[dbrgn]

I don't understand the difference between during peer handshake and after peer handshake. Could you elaborate?

During the peer handshake, a message can come from any responder in the valid responder range. After the peer handshake, only the "chosen" responder may be the source. Right?

Additionally, SN SHALL also be random.

That's not something we can validate.

Incremented by 1. Nothing else is acceptable as this is a reliable and ordered channel. Note, that we're assuming here that there is no message in between a client-to-client message that produces a 'send-error' and a following message. However, 'send-errors' are only recoverable during handover stages anyway.

So should we handle things differently before and after handover?

[lgrahl]

During the peer handshake, a message can come from any responder in the valid responder range. After the peer handshake, only the "chosen" responder may be the source. Right?

I think the initiator should always accept messages from other responders. What if the currently authenticated responder's connection dies and it reconnects immediately? It'll be assigned a different identity. And if the initiator would not react to its messages, it would have to wait until it realises the previous connection is dead (e.g. by a send-error or not at all for a long time if there is nothing to send).

Additionally, SN SHALL also be random.

That's not something we can validate.

Indeed. But from the sender's side. :)

So should we handle things differently before and after handover?

What do you think?

[dbrgn]

What do you think?

Is there any downside to always checking that a) the counter is higher and b) the increment is < e.g. 16? The important thing is that the CSN is never reused. Package loss should not occur when using reliable transport protocols (unless when we do the handover, but there we have the send-error messages).

[lgrahl]

Yeah, I think so too. So, no change. Also, the current spec in the task-webrtc branch states that the same CSN of the original signalling channel will be transferred and reused by the wrapped data channel of the handed over signalling channel.

[dbrgn]

So, no change.

No, currently the spec says that the CSN must be increased exactly by 1.

[lgrahl]

Oh, sorry, I thought you meant the behaviour (e.g. handle things of the CSN differently before and after handover - to which we, I think, both agree the answer is no).

Yeah, the spec says +1 and I think that's the way it should be as the channel is reliable and everything else would indicate that the implementation is broken.

[lgrahl]

Then again, you're right... that's a problem when a wrapped data channel is unordered.

[dbrgn]

Not just that, but when doing the handover to an ordered data channel, old packets that have still been sent to the websocket may get lost. If 1 packet gets lost, then the first message to the data channel will have a CSN incremented by 2 (as seen by the peer).

[lgrahl]

Right. That makes the CSN validation rather tricky. So, since we need a sliding window of the CSN for unordered/unreliable wrapped data channels, we might as well apply that sliding window technique to the original signalling channel as soon as the task kicks in. Thoughts?

[dbrgn]

Thoughts?

Same as before - is there any downside to applying a sliding window from the beginning? If yes, I'm fine with switching logic as soon as the task kicks in. If not, let's just go with a sane default, e.g. sliding window of 16.

[lgrahl]

Having a sliding window for a reliable signalling channel doesn't make sense to a bright reader that hasn't read the WebRTC task spec yet - then again he needs to implement it anyway to support that task or have a VERY flexible implementation. Personally, I want to have the strict validation as it is a good indicator for bugs in new implementations.

I think we should be a little teasing here and state in the spec that a sliding window technique for the CSN MUST be used but that the window size is 1 until a task decides otherwise 😁. That should be fairly easy to implement. WebRTC task will kick in, set it to 16 and done.

[dbrgn]

Fair enough :)

[lgrahl]

The sliding window sounded fairly easy but is an utter pain to implement, not to mention describing it in the specification. So, this is what I have in mind:

• Leave the CSN validation as it is in the protocol spec
• Disable CSN validation for wrapped data channels in the WebRTC task protocol spec
• Add a handover message to the WebRTC task. Before this message, no message shall be received on the wrapped data channel for the signalling. After this message, no message shall be received on the original signalling channel. Both clients can close the original signalling channel after both have sent a handover message. No lingering needed.
• Drop re-sending completely after a send-error. A send-error is not recoverable and just exists to ensure a reliable communication channel. This way we can completely avoid the headache of unordered messages on the signalling channel.