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

[Tim Wilson-Brown - teor]

> On 3 Oct 2015, at 13:34, Tom van der Woerdt <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.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151004/1dd38ff6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151004/1dd38ff6/attachment-0001.sig>