[tor-dev] Proposal: Load-balancing hidden services by splitting introduction from rendezvous

Tom van der Woerdt info at tvdw.eu
Sun Oct 4 12:58:30 UTC 2015

Op 04/10/15 om 06:46 schreef Tim Wilson-Brown - teor:
>> On 3 Oct 2015, at 13:34, Tom van der Woerdt <info at tvdw.eu
>> <mailto:info at tvdw.eu>> wrote:
>> ...
>> 3. Compatibility and security
>> The implementation of these methods should, ideally, not change
>> anything in the network, and all control changes are opt-in, so this
>> proposal is fully backwards compatible.
>> Controllers handling this data must be careful to not leak rendezvous
>> data to untrusted parties, as it could be used to intercept and
>> manipulate hidden services traffic.
> After thinking through this, I wonder if the rendezvous data should
> contain the decrypted cell, rather than the introduction point key and
> the encrypted cell. That way, if an INTRODUCE event is exposed, only the
> one rendezvous referred to by the event is vulnerable. (Exposure of the
> introduction point key means that all introductions from that point are
> vulnerable until it is rotated, however, there are other layers of
> encryption protecting the INTRODUCE2 cells [but we shouldn’t rely on
> these, because we want defence-in-depth].)
> This is also slightly more efficient, as we are transmitting less data
> in the INTRODUCE event.
> The drawback of this change is that decryption places slightly more load
> on the tor instance that receives the INTRODUCE2 cell.

I don't have a particular opinion on which to pick. The proposal leaves 
this decision up to the implementation for exactly that reason.

There are several things to consider that I can think of:
  * If the crypto is done on the rendezvous side, HSes could potentially 
scale better and be more resistant to DoSes;
  * With up to 60 introduction points (= processes) made possible by 
OnionBalance, the perf difference may not matter any time soon, and 224 
should make HSes perform better anyway;
  * If the crypto is done on the introduction side, DH replays could be 
detected better, which may be good against DoSes;
  * The controller is considered trusted, and connections between the 
controllers needed for this proposal can be encrypted;
  * The overhead of constantly adding the same key into the events can 
largely be negated by using a fast compression algorithm such as Snappy 
-- although I don't think that these introduce events will ever become a 


PS: So far this thread has been between Tim and myself... Does anyone 
else have an opinion? ;-)

More information about the tor-dev mailing list