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

[Tim Wilson-Brown - teor <teor2345@xxxxxxxxx>]

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)

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev