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