[tor-dev] Proposal: Single onion services

[David Goulet]

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.

+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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150906/33c5a94c/attachment-0001.sig>