[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Shared random value calculation edge cases (proposal 250)
Tim Wilson-Brown - teor <teor2345@xxxxxxxxx> writes:
>> On 21 Nov 2015, at 04:14, Michael Rogers <michael@xxxxxxxxxxxxxxxx> wrote:
>>
>> On 20/11/15 16:24, David Goulet wrote:
>>> # Consensus
>>> (This goes for both previous and current SRV)
>>> if SRV in consensus:
>>> dirauth MUST keep it even if the one they have doesn't match.
>>> Majority has decided what should be used.
>>> else:
>>> dirauth MUST discard the SRV it has.
>>
>> This seems like an excellent idea. Relying on the consensus ensures that
>> no matter what crazy shit happens to the individual dirauths, they can
>> eventually converge on the same previous and current SRV values (or
>> agree that no such SRV values exist) by sharing the valid consensus
>> documents they've seen.
>>
>>> Side effect of only keeping SRV that are in the consensus. If one voting
>>> round goes bad for X reason and consensus end up with no SRV, we end up
>>> in bootstrapping mode that is no previous nor current SRV in the
>>> consensus which is problematic because for 48 hours, we won't have a
>>> previous SRV which is the one used by everyone.
>>>
>>> I don't see a way to get out of this because consensus is decided from
>>> the votes deterministically thus if not enough vote for SR values, we'll
>>> end up with a consensus with none so this is why client/HS have to
>>> fallback to a disaster value by themselves I think which can NOT be
>>> based on the previous SRV.
>>
>> If there's no consensus on a fresh SRV for a while, clients and relays
>> can keep producing emergency SRVs by hashing the last fresh SRV they
>> know about, right? It doesn't have to be yesterday's SRV - if the last
>> fresh SRV was produced a week ago, they keep hashing based on that
>> (which is not ideal of course). As above, using the consensus seems like
>> a good idea because it allows the network to converge on the same values
>> just by sharing valid consensus documents.
>
> If there's no consensus on a fresh SRV, why not just use the disaster recovery procedure?
>
> That is:
>
> # Consensus
> if majority agrees on SR value(s):
> put in consensus
> else:
> put disaster recovery SR value (based on last round's agreed SR value, if any) in consensus
>
> Output: consensus is created
>
> (Proceed like the 16:00 period)
>
True. However, if the majority cannot agree on SR values, how can a majority be
formed to agree on disaster recovery SRVs? The problem here is that the disaster
SRVs are derived from the previous SRV.
> That way, clients and relays don't need to do anything special: there will always be a SRV in the consensus.
>
> This means that the SR consensus method will always produce a SR value, which I believe is a much better property than occasionally failing to produce a value.
>
Indeed, that's something very important.
Yesterday, we were discussing with David how bad it would be if 2-3 SR-enabled
dirauths drop offline during voting, and the rest dirauths generate a consensus
without an SR value (because the consensus method requirement for SR failed or
something).
In this case, some clients will have a consensus with an SR value, and some
other clients will have a consensus with no SR value. Those two client sets will
use a different formula to connect to hidden services, bringing out terrible
reachability consequences.
I wonder what's the solution here. We don't want a single consensus to break
reachability for all hidden services. I wonder what should we do? Should we just
make it ultra unlikely that a consensus will be generated without SR values?
For exmaple, we could require every dirauth to participate in the protocol so
that we either have a consensus with SR or no consensus at all. This will slow
down deployment, but it might make the system more bullet proof.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev