Figure out how to deal with network spam / DoS attacks

[oskarth]

Understand what attack vectors are possible here, study prior art and write up trade-offs / justification for given choice.

Some raw notes:

• One approach is to use a Friend-to-Friend (F2F) network. This is what Briar and Secure Scuttlebutt (SSB) does.
• For open DHT-based, another approach is to rely on proof of work like Whisper. This isn't very practical for mobile / resource restricted devices, and appears to have limited usability.
• More approaches are likely possibly, such as traditional rate limiting, basic peer reputation, payments, etc.
• Barry Whitehat has some ideas around using SNARKS to prevent spam
• Global network attacks more relevant here than a specific node being attacked. What does this imply for a DHT?

[robertkiel]

I think there are basically three directions how to have spam protection:

1. Using whitelists like a Friend-to-friend / Web of Trust network or some whitelist / KYC provider(s) who provide nodes with reasonable whitelists
2. Using techniques known as Proof-of-Work where people proof that they've spent some resources (computation, space, electricity and so on) to show that they have no incentives to spam you
3. Using techniques close to Proof-of-Stake where people spend / stake something that is valuable for the delivery of the message

I would prefer the third direction because:

• it doesn't waste computation / resources like Proof-of-Work
• it doesn't need that much trust that whitelist provider need
• it is easier to build a big network with arbitrary people than sticking to close friends

[oskarth]

I agree staking schemes would be desirable. It also means you can have both staking and non staking entity, then sort by some metric, which leads to graceful degradation/interop with other ecosystems.

Staking assuming it's simple and cheap enough to get the necessary information. Any thoughts on slashing conditions and griefing factors?

[burdges]

There are two very separate issues here:

SPAM: If we adopt my "contact point" vs "aggregation point" design, or any modern design, then SPAM protection is almost automatic, except for "new contact" SPAM from any publicly representable address. In fact, the SURB based design naturally limits this, but if we should prevent overloading by providing some "filter". We should eventually provide an "introduction" mechanism to bypass the "new contact" overload filter, as SURBs lend themselves to this. As for the filter itself, we should have all individual presentations of publicly representable addresses contain a unique identifier, so that SPAMers must obtain the same address numerous times.

DoS: There are numerous tricks for hardening the network against DoS attacks without touching the mixnet layer, but ignoring those one might further subdivide in network border vs internal protections, and how they interact. We do not need anything as heavy as SNARKs for this, but rerandomizable certificate schemes help because they apply equally at the network border and internally. In particular, Coconut has some backers in the Panoramix community. I see two concerns:

1. efficiency: I dislike that verification requires four pairing computations, but we can batch them across all packets received in some flexible time window. Assuming the packet delays are generated form the key exchange then an adversary can only shorten this time window by doing considerable computational work. And maybe nodes can arbitrarily delay longer to maintain their aggregation levels.
   2. usability: I fear the real problem is: How do users obtain their rerandomizable certificate? An interesting but complex approach might be a rerandomizable certificate "chain" issued by the guard node that hides the guard node itself, but this starts to make Coconut's second NIZK heavier.

I think proof-of-CPU-work does not help address any issues here.

A priori, proof-of-stake is not user friendly since users are unwilling to spend any resources on anything. In principle, we could make proof-of-stake work with centralized resources like phone numbers, so what WhatsApp, etc. do, but this tends towards centralized infrastructure. We could "disconnect" from that centralized infrastructure if the messaging program pays users for correctly generating their cover traffic, but this still ultimately requires some proof-of-stake from users.

[robertkiel]

A priori, proof-of-stake is not user friendly since users are unwilling to spend any resources on anything.

This is absolutely correct. But I would argue here from another perspective and compare this with "offline" communication. For example, when you want to talk to somebody or meet this person in person, then you will have to invest some money for public transport and additionally some amount of time to get to the that person. That concept acts as a "natural" spam protection. It might be wise to adapt it when building a spam protection for a messaging protocol.

[burdges]

I'm unconvinced that incentivization can charge enough money to prevent SPAM because cover traffic combined with low fees means SPAM costs very little.