This discussion started when David asked me how I would forge messages. I pointed out that the client was currently trusting and communicating through a single proxy. That single proxy could generate forged messages easily and the client would not be able to tell even if it knew the prefix of the group it wanted (because it could be easily generated by the malicious proxy node). An entire data chain could be forged too. The main takeaway is that messages can be forged easily in this system.
Knowing every member of your group, and the adjacent group is not web-of-trust exactly. Its more like strength in numbers - you don’t necessarily know who is running any of those nodes (although you might make a dedicated connection to a friend). The ideal situation is that somehow a client can immediately detect a forgery by “knowing” that the network address was not provided by the network. I am not sure how to do this, so the system has to eliminate scenarios where a client chooses the wrong one (like the single aforementioned proxy case). Again with the bitcoin, if you have 8 peers and 7 of them are maliciously working against you, the single peer forwarding the longest chain is enough to determine the valid messages (assuming the whole 51% thing). Very simple.
The client could connect to multiple proxy nodes in an attempt to collect multiple responses. If it gets different results, which one does it trust? The “closest” nodes (previous attempt) is probably not a good idea. The quorum? Can the system guarantee that quorum will never drop in this environment (through churn, etc.)? Does it then just become a majority “vote”? If you decide to let quorum drop (for churn, etc.) then it creates an incentive for a malicious node in the group to forcible delay responses from its peers (via overload) to influence the “vote” going through the system (which of course depends on how low of a “vote” can be accepted). And then there’s the possibility of me continually joining the network through different IPs to be “randomly” assigned to the same group. The number of groups is based entirely on the size of the network and targeted group size with disjoint groups. Has anybody thought about the expected number of groups, and the probability of an attacker getting into a desired group?
I will refrain from saying much further, because it is easier to review with an implementation. Its difficult to know exactly (due to subtleties of language, etc) what the team is planning based just on some RFC. Just think about: (1) An attacker can generate a public key within a certain prefix, (2) an attacker can generate messages claiming to be from that group, and (3) how does the client detect forgeries. Data chains can be forged too.
The design is still allowing legitimate correctly functioning nodes to have a history fork in ways that can be hard to predict (IMO). Eventually consistency implies that somehow the recorded history forks, and then later merges. Can an attacker induce this behavior to their advantage?
I can influence the vote count by placing a machine under load. I mentioned on github on how the vote gets tallied incorrectly. This one is more difficult than the DDoS case for sure, but is heavily dependent on the implementation (especially data structures). I would look for a data structure that allows me to remotely control the length of time required to complete a function call on the path that I wanted to slow down (i.e. a linear search that I can add entries to remotely). So its heavily dependent on the implementation, which hopefully isn’t changing very often.
The single malicious node in the group is also an issue in that patch. Assuming the network chooses a location for me, how long will it take for me to get a single node in the group I want? Once I am in there, the attack is even easier than before. I send two opposing messages from the client like before, and then I “split the vote” (from the single node I control in the group) giving each half of the group I different value. Now my value is the deciding “vote” for the quorum. Reverting the recent patch would fix this, but I still have the prior attack and potential usability issue (3-writers is the funny case).
You are absolutely correct. I was speaking to the current implementation specifically. I stated this earlier, my first thought (thinking like an attacker) would be finding a way to generate a key I wanted, then find a way to get nodes in a position to forge a network join. I would need more detailed information than this diagram though.
But one thing to think about - the number of groups is directly related to the size of the network and the target for the group size. How many groups are expected? How difficult would it be for an attacker to take 50 machines and slowly attempt rejoins until they are in the same group? Its going to be easier with a small network.
This is a great question. I actually thought about this for a few minutes, because I am not sure myself. No one has publicly requested for my feedback directly, and this is taking up too much of my time. I cannot see any sort of payoff for me in this - monetarily or mentally.
This is my main concern. Lots of moving parts. The details change frequently too, which makes it hard to analyze.