p0s asked me to post some details on this. GROUND RULES:
1. Everything is specific to a single forum, on the theory that the number of active users on a forum is likely to be limited. 2. We are only concerned with demonstrable DoS attacks here. Trolling and "slow" attacks can be dealt with either by the user, or by using WoT, which is otherwise unnecessary with this architecture. In other words, it doesn't solve all spam problems, and it's not intended to. Ultimately it relies on some sort of non-trivial announcement system, as does WoT. DETAILS: Identities announce to the forum via some globally visible mechanism: Scarce SSKs, hashcash or similar. We might approximate this with CAPTCHAs where the solutions are published after a fixed period. Every user creates a PSK queue. This has two components: - A public queue. This can be posted to by any identity where the owner has signed their pubkey. - An emergency channel. This can only be posted to by the owner. Users automatically join several other users' PSK queues, and post to all of the PSK queues that they are "on", including their own. The forum tool polls all active users, but some of them it will poll via other users' PSKs. This means we only have to poll a small subset of the total number of PSKs. We will need to ensure that there is some clustering to limit the number of queues we poll, but we don't want too much centralisation. We can in any case leave any PSK queue simply by posting a message saying so. The initial guesstimate parameters are 100 users per PSK queue, and When a user starts a DoS attack, this is detected in some deterministic way, probably after say 100 consecutive messages from that user. All subscribers stop listening to that PSK queue, and poll the emergency channel for a redirect. This may mean they have to poll more PSKs to get all the messages from the other users. When the PSK owner detects such a DoS attack, his instance will generate a new PSK, post the first edition, and post a redirect to it on the emergency channel. The first edition of the new PSK will include: - The last PSK which had a real message posted to it. (Not necessarily the one we were just watching!) - The edition at which the spam attack started. - The editions of any real messages posted after the spam attack started. Optimisation: - Include the actual messages, or even point to a CHK containing an archive of them. Further optimisation: - The PSK owner posts archives regularly, e.g. every day, and not just when changing PSKs. Either way, the subscribers keep the owner honest: - If he does not react to spam, he is a spammer. - If he does not include a valid message in the editions (or archive), he is a spammer. - If he includes messages in the archive that were not posted, he is a spammer. (There might be some difficulties with different PSKs/SSKs being visible on different nodes, but this is a solvable problem; e.g. PSKs allow for something like MSKs, where we post the same data to multiple locations in such a way as to allow healing) - If he excludes somebody who didn't post spam, we can detect this and poll them via other PSKs. - In most of these cases, anything bad the PSK owner does can be proven, and the other identities can post about it on the PSK, unless he's already excluded them, in which case they can post on their own PSKs if necessary. PSK details: - A PSK includes the pubkey of the owner, and a list of hashes of pubkeys not allowed to post (in spite of having been signed at some point). You can post if you have a signature from the owner and are not on the list. - The signature (certificate) is given out when you join a PSK. - When the owner creates a new PSK, normally they reuse the master pubkey and add to the blacklist. However when the blacklist is full they will need a new master pubkey, will clear the blacklist and include signatures for all currently valid posters (i.e. not including the spammer). p0s's main concern was the effect of spam on downloading the history. IMHO this is a solved problem. Even if we assume that there is constant spam, when downloading the history: - In the most naive implementation, we download 1 redirect and 1 real message for each message. We download no spam. This is IMHO acceptable: it's O(N) with N = number of *real* messages. - In an optimised implementation, the real message and redirect usually fit in one key, so we download only one message for each real message. - In a highly optimised implementation, we download the archives, which don't include spam. IMHO the result is that we can download history considerably faster than with the current Freetalk/WoT code, or even compared to FMS, even without auto-archiving. Certainly once we are up to date, having to poll only a fraction of the active posters will greatly improve performance compared to polling all of them (or even more).
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
