[tor-dev] Proposal: Single onion services

[Mike Perry]

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.

>  * (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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150905/74987d3f/attachment.sig>