[tor-dev] Walking Onions status update: week 2 notes
nickm at freehaven.net
Sun Mar 29 20:56:35 UTC 2020
On Fri, Mar 20, 2020 at 12:38 PM teor <teor at riseup.net> wrote:
> Hi Nick,
> > On 20 Mar 2020, at 23:01, Nick Mathewson <nickm at freehaven.net> wrote:
> > On Wed, Mar 18, 2020 at 11:21 AM teor <teor at riseup.net> wrote:
> >>> On 14 Mar 2020, at 14:44, teor <teor at riseup.net> wrote:
> >>>> * As I work, I'm identifying other issues in tor that stand in
> >>>> the way of a good efficient walking onion implementation that
> >>>> will require other follow-up work. This week I ran into a
> >>>> need for non-TAP-based v2 hidden services, and a need for a
> >>>> more efficient family encoding. I'm keeping track of these
> >>>> in my outline file.
> >> Here's another issue you might want to consider:
> >> Currently, new relays get in the consensus as soon as:
> >> * they post their descriptors, and
> >> * a majority of authorities can contact their ORPorts.
> >> That means clients and relays waste a whole bunch of bandwidth
> >> downloading consensus info and descriptors for relays with very
> >> low weights.
> >> Instead, we could have two documents:
> > Thanks for this! This dovetails nicely with some of the voting design
> > work I'm up to right now.
> It would be great to have a protocol that doesn't depend on:
> * time synchronisation
> * big documents
> * one-shot updates
> * absolute consistency
Hi! I think that _some_ of these changes are orthogonal to the shifts
we'll need for walking onions, but some of them do dovetail nicely.
I'm going to keep this email as a note to myself, so that I can
double-check whether any of these items are precluded by choices I'm
making in the design space.
> We've already made vote timing a bit more robust in the tor master
> branch, by ignoring late votes:
> Here's a few other tweaks that might help:
> Tor halves the consensus interval when there is no fresh consensus.
> But changing the interval makes tor's code much more complex.
> Instead, let's have a fixed consensus interval. And make it long
> enough for efficiency, but short enough to recover from a failed
This makes sense; I'd forgotten that we did this.
> Let's support vote diffs, as well as consensus diffs. Vote diffs
> don't help when posting votes. But when requesting votes, authorities
> can include hashes of votes they already have. That way, authorities
> that are under heavy load are more likely to get all the votes.
Actually, we *can* do them when posting votes; I've sketched out a
design here in the work-in-progress voting spec.
> We could increase the time that authorities have to fetch votes, and
> make them retry fetches every few minutes.
> We could do consistency checks on smaller shards, so that a
> consistency failure in any one document does not break the entire
This seems like something we could do as a followup here? It does seem
like it could get pretty complex.
> We could create a shard for each supported consensus method (like we
> do microdescriptors). That way, a consistency failure in any one
> consensus method does not break the entire consensus.
Hm, interesting. This would involve generating multiple consensuses
with different methods? It sounds orthogonal to me, but quite
possibly a good idea. But we'd have to withhold signatures on older
consensus methods until we're sure that the newer ones are failing --
and I worry about attacks where we _cause_ a newer consensus method to
be inconsistent specifically so we can force an older one.
I also worry about mix-and-match attacks on the different shards.
> We could make shards valid for a longer time, so that if the
> replacement shard does not reach consensus, the older one is used.
> Then, the final documents are a combination of all the consistent
> shards, using the highest consistent consensus method. (Much like
> the current microdesc consensus.)
> Once we've made some of those changes, then some other changes
> become plausible:
> Let's make votes valid for exactly 2 voting periods, and use the
> latest available vote from each authority.
Hmmm. So this doesn't help us much in the case when an authority goes
down -- it just means that its vote counts for an extra hour more than
it would otherwise. That would buy us an hour of extra consensus time
-- but it would only be a big improvement if the authority is
-regularly- failing to upload a vote. For that case, I think it might
make more sense to address the reliability problem directly instead
of trying to work around it.
I dig the idea of dropping time synchronization if we can; let's look
into this more. It seems like something we can do orthogonally to
walking onions, though?
More information about the tor-dev