[tor-dev] Hidden Service Scaling

[Christopher Baines]

On 10/10/13 23:28, Paul Syverson wrote:
> On Wed, Oct 09, 2013 at 03:02:47PM +0100, Christopher Baines wrote:
>> On 09/10/13 11:41, Paul Syverson wrote:
>>>>>> These two changes combined should help with the two goals. Reliability
>>>>>> is improved by having multiple OP's providing the service, and having
>>>>>> all of these accessible from the introduction points. Scalability is
>>>>>> also improved, as you are not limited to one OP (as described above,
>>>>>> currently you can also have +1 but only one will receive most of the
>>>>>> traffic, and fail over is slow).
>>>>>  
>>>>> Do you see any disadvantages to this design?
>>>>
>>>> So, care needs to be taken around the interaction between the hidden
>>>> service instances, and the introduction points. If each instance just
>>>> makes one circuit, then this reveals the number of instances.
>>>
>>> You said something similar in response to Nick, specifically you said
>>>
>>>    I believe that to mask the state and possibly number of instances,
>>>    you would have to at least have some of the introduction points
>>>    connecting to multiple instances.
>>>
>>> I didn't understand why you said this in either place. Someone would
>>> have to know they had a complete list of introduction points to
>>> know the number of instances, but that would depend on how HS descriptors
>>> are created, stored, and distributed. From whom is this being hidden?
>>> You didn't state the adversary. Is it HS directory servers, intro point
>>> operators, potential clients of a hidden service?  I don't see why
>>> any of these necessarily learns the state or number of instances
>>> simply because each intro point is chosen by a single instance
>>> (ignoring coincidental collisions if these choices are not coordinated).
>>
>> To clarify, I was interpreting the goal as only the service operator
>> should know the number of instances. In particular, the adversary here
>> is the introduction point. If hidden service instances only ever create
>> one circuit to each introduction point, each introduction point knows
>> the number of instances of every service it is an introduction point
>> for, as this is the same as the number of circuits for that service.
>>
> 
> I'm missing something. Suppose there is a hidden service with ten
> instances, each of which runs its own introduction point. How do any
> of these ten introduction points know the number of instances because
> they each see a single circuit from the hidden service?

Ah, I have not been explicit enough when describing the behaviour I want
to implement. In my original email, I set out that each instance of the
service connects to each introduction point (this has also
developed/changed a bit since that email). Unfortunately, I did not
state the resultant behaviour I was looking to achieve (the above), just
the changes to the protocol that would result in this behaviour.

>>> Also, in your response to Nick you said that not having instances share
>>> intro points in some way would place an upper bound on the number of
>>> instances. True, but if the number of available intro points >> likely
>>> number of instances, this is a nonissue. 
>>
>> I don't really follow your reasoning.
> 
> If there are a thousand possible introduction points for a given HS,
> if each instance runs say two intro points, then that bounds the
> number of instances at 500 (ignoring that the intro points for different
> instances overlap q.v. below).

I think this resolves itself with the above clarification.

>>> And come to think of it,
>>> not true: if the instances are sometimes choosing the same intro points
>>> then this does not bound the number of instances possible (ignoring
>>> the number of HSes or instances for which a single intro point can
>>> serve as intro point at one time).
>>
>> Ok, but I was assuming the current behaviour of Tor, which I believe
>> prevents instances using some of the same introduction points.
> 
> Why? If two different instances of the same HS operated completely
> independently (just for the sake of argument, I'm assuming there are
> good reasons this wouldn't happen in reality) then they wouldn't even
> know they were colliding on intro points. And neither would the intro
> points.

Given my above clarification, the instances perform some coordination
via the hidden service directories. When a new instance starts, it finds
existing introduction points in exactly the same way a client (who wants
to connect to the hidden service) does.

>>> Also, above you said "If each instance just makes one circuit". Did
>>> you mean if there is a single intro point per instance? 
>>
>> No, as you could have one instance that makes say 3 circuits to just one
>> introduction point. This can help, as it can hide the number of
>> instances from the introduction point.
> 
> Off the top of my head, I'm guessing this would be a bad idea since
> the multiple circuits with the same source and destination will create
> more observation opportunities for either compromised Tor nodes or
> underlying ASes routers, etc. I don't have a specific attack in mind,
> but this seems a greater threat to locating a hidden service than
> would be revealing the number of instances to an intro point (which
> I still don't understand your argument that this gets revealed anyway).

That is a concern. This will need more thought.

>>> Hard to say specifically without exploring more, but in general I
>>> would be more worried about what is revealed because circuits are
>>> built to common intro points by different instances and the intro
>>> points can recognize and manage these, e.g., dropping redundant ones
>>> than I would be because the number of intro points puts an upper
>>> bound on instances.
>>
>> I don't quite understand the last part, but regarding introduction
>> points handling more that one circuit for the same service. I think that
>> having this helps possibly hide information (like the number of
>> instances). This does depend on also allowing one instance to use
>> multiple circuits, otherwise, some information would be given away.
>>
> 
> I think our miscommunication above is just reiterated here. Hopefully
> something I have said will spark you to recognize the confusion (and
> indicate to you which one of us is having it) and you can tell me.

I think this has now been addressed, let me know if it has not.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20131013/242487a8/attachment.sig>