[tor-dev] Shared random value calculation edge cases (proposal 250)

[George Kadianakis]

Tim Wilson-Brown - teor <teor2345 at gmail.com> writes:

>> On 21 Nov 2015, at 04:14, Michael Rogers <michael at briarproject.org> 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.