[tor-dev] Update of prop#250: Random Number Generation During Tor Voting

[George Kadianakis]

teor <teor2345 at gmail.com> writes:

>> On 29 Oct 2015, at 05:26, David Goulet <dgoulet at 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!