[tor-dev] Hidden Service Scaling

[Christopher Baines]

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.

> 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.

> 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.

> 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.

> 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 might try creating a wiki page on the Tor wiki to collect all of the
information in this thread, as it might be a nice reference for discussion.

-------------- 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/20131009/46506ab3/attachment.sig>