[tor-dev] Proposal: Single onion services
dgoulet at ev0ke.net
Sun Sep 6 08:21:13 UTC 2015
On 05 Sep (14:47:41), Mike Perry wrote:
> Yawning Angel:
> > On Fri, 4 Sep 2015 15:31:15 -0600
> > John Brooks <john.brooks at 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.
> 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:
Splitting 224 into "modules":
Needed code refactor:
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.
> > * (The technical objection) It is overly easy for assholes 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 at lists.torproject.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: Digital signature
More information about the tor-dev