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

[Tim Wilson-Brown - teor]

> 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)

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.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151121/d368701f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151121/d368701f/attachment-0001.sig>