Include a coarse timestamp to prevent replay of old messages

[boramalper]

ysleepy on Hacker News said:

Maybe messages should include a coarse timestamp to prevent replay of old messages by some adversary.

Someone could resend a month old "yes" with your valid signature to a question someone asks now.

Also it might be beneficial to include sequence numbers or message IDs and for example echo the last 4 ids in following messages so recipients can detect holes. - The chat could insert some placeholder to notify recipients of missing previous messages.

[kmarekspartz]

Replay could be used to reliably find missing messages. I was wondering about including a “greatest known message signature” field to create a distributed hash table of messages.

This would also make “replay” difficult, because it would reference an old message.

[brannondorsey]

Very excited to see discussion around this topic! I think a solution for preventing replay attacks is a must with the next update of the protocol and I'd love to use this thread as a platform for discussion about this topic in general.

So far, here are my thoughts:

• I'd like to solve this problem in a connectionless way. Let's keep chattervox a connectionless protocol, at least for now.
• A timestamp is perhaps the best solution to this problem provided machines have somewhat synchronized clocks. There is a trade off at play here where with security via this mechanism we also lose the ability for machines to disagree about the time, especially in instances where these machines have no means of knowing what time it is (no internet and no means of tracking time when powered off). I'm happy with this solution so long as it is opt-in. I don't want to impose time synchronization into the protocol.
• Adding sequence numbers to packets could be another solution, although it comes with a few drawbacks of its own.
  • The main problem I can think of with sequence numbers is that a station would be vulnerable to replay attacks for messages that were sent after communication with a station had ended. E.g. Alice and Bob are communicating in a round-table discussion in the CQ "chat room". The last message Alice hears from Bob before logging off contains sequence number 43. Once Alice has logged off, Bob continues to chat in the group and sends 100 messages, which Eve records. The next day, Alice joins the CQ while Bob is not present. She is vulnerable to replay attacks by Eve for 100 different messages that Eve heard but Alice did not. Because Bob is no longer in the room, he can not inform her that his next sequence number is 144.
  • Sequence numbers don't play nice when a station uses two different computers, each with their own message sequence counters. Support for SSIDs (e.g. KC3LZO-1, KC3LZO-2, ...) mitigates this problem to some degree.
• Adding message nonces solves the problem in a similar way to sequence numbers. Each message could contain a fixed-width random number (16 bits at minimum but 24-32+ bits would be better, at the expense of more overhead) which can be used to as a globally unique identifier for the message. Clients could store all nonces from received messages as they please (e.g. in a bloom filter). A nonce field can be beneficial for more than just replay attack prevention as well, for instance, in duplicate message pruning when the same message is received more than once because of digipeating etc. Unfortunately, the nonce solution only protects against message replay for messages that a station has already heard. A station remains vulnerable to replay attacks from messages they have never heard (but that an attacker did).
• Perhaps whatever solution we go with could remain optional. For application uses where replay attacks aren't an issue, they could opt-out of it entirely and reduce packet size overhead. We could add bit flags (from the currently reserved bit fields) that indicates the inclusion of a timestamp, sequence, or nonce in the packet.

[brannondorsey]

I've opened an RFC to include a timestamp in the chattervox protocol #19.