[tor-dev] Proposal: Single onion services

[Aaron Johnson]

Hello,

Nice, concise proposal! I’ve been meaning for a while to send some comments:

Overall:
	1. This proposal doesn’t allow you to run a single-onion service if your server is behind NAT. It might be useful to include an option for the SOS to create persistent connections to some guards that will also serve as rendezvous points.
	2. This proposal doesn’t allow a single-onion services to hide its existence. It is possible to hide its existence unless you know enough to request the descriptor, but it would seem to require using guards or a malicious relay will eventually be selected to connect directly to the SOS.
	3. I suggest using “single-onion service” throughout because it makes it clear that “single” modifies “onion” and not “onion service”. I disagree with the suggestion from Jeff Burdges that this term is “grammatically” inaccurate. At worst, it might suggest that only a “single onion” is ever used. However, Tor actually doesn’t use onions at all, which I can only understand to mean repeatedly-encrypted data structures that contain no actual payload. So “onion routing” is just as inaccurate. “Single onion” to me refers to the use of a multiply-encrypted tunnel from a “single” member of the communicating pair, and I think that works just fine.
	4. To respond to the suggestion by Jeff Burdges, I wouldn’t prefer “Directly Peered Rendezvous Service”, because it is cumbersome (intentionally, I understand), and it will need to be used frequently at least to remind people what the unintuitive “DPR” acronym refers to. I also rather dislike the collision with “Dread Pirate Roberts” of Silk Road fame, which I would rather not steer Tor into.

Sec 5.1: "Configuration options… RelayAllowExtend 0|1 If set, allow clients to extend circuits from this relay… PublishServerDescriptor must also be disabled if this option is disabled… If ExitRelay is also disabled, this relay will not pass through any traffic.”

This doesn’t make sense to me. By "allow clients to extend circuits from this relay” I take RelayAllowExtend to indicate that a relay will extend circuit *through* itself. But then why should it be that "PublishServerDescriptor must also be disabled if this option is disabled”? Wouldn’t you want to disable RelayAllowExtend and enable PublishServerDescriptor to run a single onion service? Also, the statement that "If ExitRelay is also disabled, this relay will not pass through any traffic.” makes it seem like it is required to disable ExitRelay in order to prohibit passing through any traffic. However, my reading of the definition of RelayAllowExtend makes it seem like disabling RelayAllowExtend is all that is required to prohibit passing through any traffic, and 

Sec. 7.1: "To prevent this, we would need to include a cookie from the descriptor in the RELAY_BEGIN information.”

It does seem helpful to be able to use an authentication cookie to prevent this attack, although single onion services shouldn’t expect their existence and location to remain unknown because they don't use guards (under this proposal). With enough connections, any one of them would eventually be connected to by every middle, including malicious ones trying to enumerate single onion services. However, SOSes could still hide what the server does by including the authentication cookie, and that seems valuable. Isn’t authentication already an option in onion services, though?

Cheers,
Aaron

> On Sep 6, 2015, at 3:21 AM, David Goulet <dgoulet at ev0ke.net> wrote:
> 
> 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
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev