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

[Michael Rogers]

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.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 1731 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/9d5ab207/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151120/9d5ab207/attachment.sig>