Re: [tor-dev] Walking Onions status update: week 2 notes

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Fri, Mar 20, 2020 at 12:38 PM teor <teor@xxxxxxxxxx> wrote:
>
> Hi Nick,
>
> > On 20 Mar 2020, at 23:01, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> >
> > On Wed, Mar 18, 2020 at 11:21 AM teor <teor@xxxxxxxxxx> wrote:
> >>
> >>> On 14 Mar 2020, at 14:44, teor <teor@xxxxxxxxxx> 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:
> https://trac.torproject.org/projects/tor/ticket/4631
>
> 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
> consensus.

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
> consensus.

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?


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