[tor-dev] Hidden Service Scaling

[Paul Syverson]

On Wed, Oct 09, 2013 at 09:58:07AM +0100, Christopher Baines wrote:
> On 09/10/13 01:16, Matthew Finkel wrote:

> >> Then comes the second problem, following the above, the introduction
> >> point would then disconnect from any other connected OP using the same
> >> public key (unsure why as a reason is not given in the rend-spec). This
> >> would need to change such that an introduction point can talk to more
> >> than one instance of the hidden service.
> >>
> > 
> > It's important to think about the current design based on the assumption
> > that a hidden service is a single node. Any modifications to this
> > assumption will change the behavior of the various components.
> 
> The only interactions I currently believe can be affected are the Hidden
> Service instance <-> Introduction point(s) and Hidden Service instance
> <-> directory server. I need to go and read more about the latter, as I
> don't have all the information yet.

Indeed. Lots of issues there.

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

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

Also, above you said "If each instance just makes one circuit". Did
you mean if there is a single intro point per instance? 

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.

HTH,
Paul