pairing timeout and stale sessions

[richard-ramos]

While testing the example app, I ran into the following problem: In Alice's webapp (the initiator), she confirmed the authcode too close to the timeout. Alice gets a handshake completed message in that webpage, but in Bob's webapp, the final handshake message did not arrive on time, so a "Pairing Timeout" error was shown.

The timeout I implemented is not exactly what is described in https://rfc.vac.dev/spec/37/#session-states but it is something temporary while we implement stale session support. In any case, once stale sessions are implemented, the scenario described above could still happen, with Bob (the receiver), assuming that a session is stale because it did not receive the last message on time.

So, besides implementing the functionality to mark a session as stale, should we also implement a way to notify that the handshake was successful? i.e: in this pattern, Alice should wait until Bob confirms that it received the message generated in the d step, to assume that the handshake pairing was completed? this confirmation message could be sent/received with the cipherstate objects obtained from finalizing the handshake.

WakuPairing:
a.   <- eB              {H(sB||r), contentTopicParams, messageNametag}
     ...
b.   -> eA, eAeB        {H(sA||s)}   [authcode]
c.   <- sB, eAsB        {r}
d.   -> sA, sAeB, sAsB  {s}

{}: payload,    []: user interaction

I'm thinking this is more of an application concern, because as far as 35/WAKU2-NOISE concerns, the handshake was done according to specs, it's just that the timeout mechanism stops the process from being completed successfully.

Or perhaps we should remove this timeout and not implement stale session functionality at all? In the meantime I increased the timeout to 2m.

cc: @fryorcraken @s1fr0 @weboko

[s1fr0]

An important detail here is that the stale mechanism detailed in the RFC is for sessions i.e., the Noise cryptographic session instantiated on completion of a Noise handshake. The problem you describe affects instead handshakes, that happen before a session is instantiated.

The successful completion of an handshake is implicit by sending and subsequently receiving a message after the handshake, because for decryption to succeed the recovered keys have to match. Since Alice is already sending a message to Bob in d., if Bob wishes to inform Alice that the handshake was completed from his side, he could send an encrypted ACK message to Alice using keys derived from Split(). However, this moves the problem you described 1 round further: Bob will receive a message that the handshake is completed but Alice may receive the ACK out of time.

In general, handshakes were designed to be performed async thanks to store nodes, so probably in the general case the timeout counter could be removed, since I don't see a real need for that.

In case of pairings, a timeout makes sense instead. However the pairing is designed so that is Alice that mainly transfers some data to Bob. Hence Bob will implicitly receive an ack that the pairing was successful as soon as he decrypts received data.

[fryorcraken]

Roadmap:

1. Simplify the noise API (sender/receiver interface)
2. Enable storage/backup of noise credentials in local browser storage
3. Enable resuming incomplete handshakes using Waku Store
4. Review timeout strategy:
   • expose it to the developer/app
   • allow a no-timeout strategy (handshake is tried until user cancels, thx to handshake that can be resumed via store).

In terms of UX, this is very similar to the Status Chat contact request:

1. Alice gives her Status invite to Bob = Alice share noise url
2. Bob receives contact request = first handshake message
3. Contact requests remains in notification draw until bob accept and reject = state saved in local storage, handshake can be resumed from Waku Store
4. Bob accept or reject request = Bob resume or abort noise handshake, no timeout strategy in place

TODO: create/link issues for the roadmap