Tim Wilson-Brown - teor <[email protected]> writes: >> On 21 Nov 2015, at 04:14, Michael Rogers <[email protected]> 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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
