teor teor2345@gmail.com writes:
On 29 Oct 2015, at 05:26, David Goulet dgoulet@ev0ke.net wrote:
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?
The protocol is already resilient because if there is a failure, it still produces a (predictable) value based on the previous value. As long as a misbehaving authority can't mess with this fallback behaviour, and as long as sufficient directory authority operators can react within 24 hours to remove a misbehaving authority, then this seems ok to me.
Thanks for the feedback teor!
A few questions:
Do we expect 24 or 48 hours of shared random downtime in the event of an incident, taking into account response time to remove an authority?
Hm, I admit I have not thought too much about the response procedure in case of an incident.
I've mainly been relying on the fact that these attacks are not worth doing, and no one is going to bother. However that sounds like a stupid thing to rely on so having an incident response procedure might be much smarter!!!
The obvious thing would be to remove the dirauth if we are sure that it was an attack. Of course, there will need to be some investigation of the "was this an attack or a bug" type that might take some time...
Maybe we should add a BadSharedRandomnessAuth flag that will block a dirauth from this protocol till the investigation is complete. Or maybe this is a stupid idea.
What would an authority do when it detects a conflict under the new proposal? Ignore it (pick the numerically higher value?) and expect DocTor to detect it?
The spec seems to say:
When a conflict line is seen in a vote, an authority should verify the commit values (see [VALIDATEVALUES]) that they are in fact coming from the authority identified by "identity" and if so, ignore that authority until the next protocol run. If the conflict line is invalid, ignore it.
More on conflict detection on my next point.
What if an authority changes shared random signing keys partway through a round?
Good question! Fortunately, I think we can handle this.
First, we include the shared randomness key in the votes of each dirauth, then we also mandate that the authoritative commitments in each vote are signed by the current shared randomness key. This means that other dirauths should always be able to verify the signatures of the commitments in a vote.
Here is a proposed procedure to handle key rotation:
1) When Alice receives a valid commitment from dirauth Bob, it saves the commitment values (timestamp, H(REVEAL), etc.) and the shared randomness public key in its state.
2) When Alice, later in the protocol run, receives another valid commitment from dirauth Bob, it needs to verify the new signature and check that the commitment values *did not change*.
If the signature is valid and the commitment values are the same, then we consider the commitment and authority trusted. How does that sound to you?
We should probably write this procedure down in the spec, maybe.
And we should also have tests to ensure that this works smoothly, because as you said it definitely happen eventually.
---
However, key rotation *does* make the commit conflict mechanism more complicated.
The reason is that when Alice receives a conflict line from dirauth Bob:
"shared-rand-conflict" SP identity SP commit1 SP commit2 NL
she doesn't know which shared randomness key to use for which commit.
If she already knows a shared randomness key for 'identity', then she can try to use that to verify both signatures. However, the conflicting attacker could have rotated shared randomness keys and could have signed 'commit2' using a different SR key than 'commit1'. In this case, if Alice does not know both SR keys, she is unable to verify the validity of the conflict line. In that case, should she trust the conflict line or not?
I guess not, otherwise Bob could just craft fake conflict lines and feed them to other auths. However, if we don't trust the conflict line, then the attacker can again partition the authorities by causing everyone to ignore Bob's conflict line, whereas Bob will of course trust his own judgement.
A way to work around that problem would be if instead of 'identity', we include both cert chains in the "shared-rand-conflict" line so that the shared randomness keys are always available for verification.
But this adds extra complexity and logic to the conflict mechanism which is kind of useless anyway, since it only defends against dumb attacks.
Does anyone have another procedure for validating shared-rand-conflict lines that makes more sense?
Thanks!