Op 04/10/15 om 06:46 schreef Tim Wilson-Brown - teor:
On 3 Oct 2015, at 13:34, Tom van der Woerdt <info@xxxxxxx <mailto:info@xxxxxxx>> 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.
TomPS: So far this thread has been between Tim and myself... Does anyone else have an opinion? ;-)
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev