On 05 Sep (14:47:41), Mike Perry wrote:
Yawning Angel:
On Fri, 4 Sep 2015 15:31:15 -0600 John Brooks john.brooks@dereferenced.net wrote:
Have you considered all the implications?
Maybe we’ve missed some - what implications are you thinking of, that aren’t addressed in the proposal?
I have two objections to this, one political, one technical:
- (The political objection) While this is "cool" and probably(?) "funded", it seems like a poor thing to work on in terms of developmental priority when there are other things Hidden Service related that need a lot of developer attention, primarily in making the existing HSes more resilient against Nation State level adversaries (Eg: Prop. 224).
We should definitely have a Tor roadmapping session at the dev meeting to cover this and related concerns.
+9000
I too have been worrying about the drift between what we suspect are the most serious problems in the hidden service protocol (and the Tor protocol in general) and the current set of Tor deliverables and dev plans (or lack thereof).
OTOH, in order to make proper roadmapping, priority, and work-ordering decisions, we really do need a good menu of well-written proposals and/or tickets to choose from, even if we're likely to decide some of them are simply not worth doing yet until other issues are solved first.
Otherwise roadmapping will become a bunch of hand-wavy statements about "Well, what about trying to solve $ISSUE_X $SOMEHOW?" without the ability to weigh the efficacy of a specific solution and how its development effort compares to (or depends upon) the gains from other potential improvements.
Last hidden service meeting in July, we were able to come up with a breakdown of components for 224. See the blog post we did a month ago:
https://blog.torproject.org/blog/hidden-service-hackfest-arlington-accords
More specifically:
Splitting 224 into "modules": https://people.torproject.org/~asn/hs_hackfest_2015/224modules.txt
and:
Needed code refactor: https://people.torproject.org/~dgoulet/hs224-refactor.txt
This is clearly not as organised as it could be but I think it's a good base from which we start on;
If the modules above make sense, having a ticket (or a family of tickets) for them and proposals (if applicable) is definitely a way to go forward that I agree on. Good example, proposal #250.
Let's have a session for that in Berlin for sure! Ideally, having an agenda before we start would be fantastic. I'll try to start tomorrow a wiki page about it and we can start from there until Berlin.
Thanks! David
(The technical objection) It is overly easy for assholes[0] to censor Single Onion Services due to:
it’s possible for the previous relay to guess the service you’re connecting to
While such a censor would only be able to deny service to clients as a fraction of their relay(s) consensus weight, it's still something that probably should get consideration.
In addition to this concern, I am also wondering about the second-order effects of what happens when we have two classes of internal services: the "boring" ones that don't use the full rend protocol, and the "interesting" ones that do, especially if we still have not solved the circuit setup fingerprinting problem to prevent an observer from easily differentiating the two before this (or a similar mechanism) is deployed.
-- Mike Perry
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev