Hello Tor-Dev!
We've almost completed the implementation [1] for prop#250 so we've reviewed part of the proposal to correct part of it to reflect reality (because you know a proposal is just wishful thinking until you implement it :).
Attached is the new version that we've been working on. We would like feedback from the community before at least calling it "ACCEPTED" and updated in tor-spec.git [2].
Here is a small summary of the big changes and also we need feedback on something that we are not fully in agreement.
First, period have been changed from 12:00 -> 12:00 (24 hour) to 00:00 -> 24:00 so the protocol run is not over two days. Seemed more logical and less confusing :).
Second, we've removed the need of having majority for a commit to be considered for the shared random computation. Yes this sounds intense!! so it needs your attention. We think that majority concept was only protecting us against was a partition attack during commit phase but it turns out that having a conflict detection mechanism (see COMMITCONFLICT section) already protect us of most of them during the commit phase except maybe one that is described in Section 5.3.1. With this proposal change, an authority only keeps commits that are authoritative that is a commit coming directly from an authority.
We've added section 5.3 on Partition Attack. Choosing commit by majority was protecting us against a partition attack in the commit phase but not all so with or without it, we still need an external monitoring party that makes sure attack are not ongoing (or bugs). DocTor is the obvious candidate so we'll work on a partition attacks detection since all of them are noisy and detectable.
A sub-section (4.1.7) has also been added which address the need of a shared random key that signs the commit values so they can be verified by other authorities [3].
Finally, we would like your opinion also on if we should keep the conflict mechanism or not?. Since those partition attacks are basically dumb, do not achive much result for an attacker and it's at a high cost of comprimising a directory authority, should we keep them? Keep in mind that it adds a layer of complexity in the code especially with shared random keys which rotates every 30 days and are only available in the vote of an authority. It gets difficult to validate a conflict of an authority if we haven't seen yet a vote from that authority. There are ways to fix that code wise but is this worth it considering that every partition attack will be detected anyway by DocTor? One argument to keep it is resilience of the protocol. With conflict line, if one dirauth does stupid things, it will get ignored for the rest of the protocol run so we can still compute a fresh random value in the end. Again, does it worth it?
Don't hesitate to ask about sections that are not clear or could be incorrect or you do not understand fully. Also, a ACK is a valid reply :).
Thanks to all! David
[1] https://trac.torproject.org/projects/tor/ticket/16943 [2] https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-c... [3] https://trac.torproject.org/projects/tor/ticket/17349