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

[Tom van der Woerdt]

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

Tom


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