[SPEC] Errors / Malicious behaviour at the message layer

[drewstone]

Overview

Lists of potential erroneous or malicious behaviour with respect to messaging (

• [x] Receiving messages from previously completed rounds (we should discard them at the earliest chance) (https://github.com/webb-tools/dkg-substrate/pull/380)
• [x] Creating Offline/Vote messages with async_index out of bounds. (Need to investigate and prevent)
• [ ] Mixing up Offline/Vote messages async_indexes to break peer signing round processing.
• [x] Receive messages from rounds higher than existing rounds (we should not process these and we can use the chain's session indices to verify this, i.e. we're in session 3 and we receive a message round 5). If I am in session i and the next DKG key does not exist, messages from session i+1 are OK. Messages from rounds greater than i+1 are NOT okay.
• [x] Messages should not be processed more than once. This needs to be handled if we receive a message multiple times over the network after we've processed. (consider eventually persistent storage of bloom filters)
• [ ] Review and update all MP-ECDSA signing errors with bad actors to ensure they don't have panics. (Right now a malicious party can make everyone panic if they manipulate their local software to send different sign message contents with the same round ID as an actively processing offline stage). We should propagate the errors. (https://github.com/ZenGo-X/multi-party-ecdsa/pull/182) (https://github.com/webb-tools/multi-party-ecdsa/pull/5)

Research

DKG functionality and known knowns (from TG chat, etc.)

• Handling duplicate message results into error
• Messages can be received out of order

Re-gossiping duplicate messages

We should consider re-gossiping messages up-to our spam threshold as long as we haven't proceeded to the next round. Or we can consider doing this after a timeout that is set after proceeding to each next round. https://github.com/webb-tools/dkg-substrate/issues/368#issuecomment-1234182464

Questions/Issues

• Should we consider having separate queues for messages of different rounds? (maybe not necessary because after genesis there should only be 1 keygen at a time)
• Should we consider having separate queues for keygen / signing? Likely the case.
• Should we maintain at any point in time the actual signing authorities for each async_index? The reason being, if we receive a message from an authority with an async_index, we verify it against the actual set, and if that authority is not in that set, we consider that slashable offense.

[dutterbutter]

@drewstone @shekohex @1xstj can you provide an update on this task. Are any of the outlined tasks above completed? And is anyone focused on this?

[shekohex]

@drewstone @shekohex @1xstj can you provide an update on this task. Are any of the outlined tasks above completed? And is anyone focused on this?

I did update the checklist of what is done and tested.