On Fri, Mar 20, 2020 at 12:38 PM teor teor@riseup.net wrote:
Hi Nick,
On 20 Mar 2020, at 23:01, Nick Mathewson nickm@freehaven.net wrote:
On Wed, Mar 18, 2020 at 11:21 AM teor teor@riseup.net wrote:
On 14 Mar 2020, at 14:44, teor teor@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: 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?