vacp2p
14-WAKU2-MESSAGE: Validating WakuMessage sender timestamp
Problem
Waku messages carry a timestamp that is generated by the user. As mentioned by @jakubgs in https://github.com/status-im/nim-waku/pull/681/files#r676126058
In general, any functionality that relies on timestamps set by the server is prone to exploit (the classic example is a message that forever stays "latest")
Context: The timestamp is the unix epoch time but not a logical clock like Lamport. And the overall assumption in our design is that nodes in the system have synchronized clocks with +-20 sec margin.
Acceptance criteria
- To review the usage of timestamp within the waku2 specs and the possible attacks
- To identify potential timestamp validation methods and their use case in waku2
Potential solution
- One way to validate a timestamp is that the receiver (assuming the receiver is authorized to have access to the timestamp) compares the received message timestamp against its own local time (UNIX epoch) and discards messages with more than +-20 secs gap (or some other upper bound depending on the network delay and clocks asynchrony). Note that the aim of this comparison is NOT to discard messages that are out of order, but to discard messages whose sender's timestamp has a huge gap with the receiver node's current time. For example, if two messages m1 and m2 arrive (m1 comes before m2) and m1.timestamp > m2.timestamp and |m1.timestamp - receiver.currenttime|<=20s and |m2.timestamp - receiver.currenttime|<=20s, then the receiving node accepts them both, it does not care about them coming out of order.
- Use of open timestamps https://opentimestamps.org/
From an application point of view, timestamp must not be trusted and if the application needs to have verifiable timestamp then other logics needs to be put in place by the application to cater this need.
Once a number of applications implements such logics it would be interesting to review whether a common standard should be proposed to help with interoperability and new projects bootstraping.
So far, we have one project that needs a timestamp: the featured communities.
Users can vote to have their community features for a week. Votes are done over Waku and are valid for 28 days. If Alice votes for a community on 1st of August but then falls out with the community and does not support it anymore, we want to ensure that Bob cannot take Alice's vote and re-broadcast it on 31st August. Hence, we need to ensure the timestamp cannot be altered.
Only SNT holders vote for communities so votes are signed with user's Ethereum accounts. The timestamp is included in the signed data to ensure Bob cannot alternate it.
This covers a specific needs where the timestamp is used to "expires" a message.
Maybe it could be worth mention in the waku message spec that the timestamp field in its current form is not verifiable?
The store spec already mention security considerations around the timestamp which is good.
IMHO, to better evaluate the proposed solutions it'd be good to review the usage of timestamp within the waku2 specs, the possible attacks and then whether said solutions helps cover it.
For example, I quickly checked the store specs and I could not find reference to the recommended 30 days storage. What timestamp is used to evaluate the age of a message? I assumed received timestamp? Maybe worth documenting at it could be an attack vector if sender timestamp is used (messages store forever).
I hope it helps, let me know if you were looking for a different kind of review.
Thanks a lot @D4nte for your great insights!
Thanks for sharing the voting scenario, that captures the need for the integrity of the timestamp and the fact that no one should be able to tamper with the timestamp of a published message.
The integrity (and confidentiality, and authenticity) should indeed hold not only for the timestamp but also for all the other fields of a wakumessage e.g., contenTopic.
Maybe it could be worth mention in the waku message spec that the timestamp field in its current form is not verifiable?
The PR is already on its way :) https://github.com/vacp2p/rfc/pull/447
IMHO, to better evaluate the proposed solutions it'd be good to review the usage of timestamp within the waku2 specs, the possible attacks and then whether said solutions helps cover it.
Agree! will do it (also included this in the acceptance criteria of the current issue).
FYI, the timestamp is currently used in the store protocol to index waku messages and to enable paging for historical queries.
For example, I quickly checked the store specs and I could not find reference to the recommended 30 days storage. What timestamp is used to evaluate the age of a message? I assumed received timestamp? Maybe worth documenting at it could be an attack vector if sender timestamp is used (messages store forever)
Good point! however, currently, we do not enforce 30 days storage limit in the store protocol. A corrupt timestamp will only cause the message to be always "recent" and being showed as the last (let's say) in a chat. This is also clarified in "Robust and verifiable timestamps" of the store protocol.
