Rendezvous handoff is partially implemented in: I think we're waiting on the following: * a more detailed specification of the handoff data fields for current and next-generation onion services, so we can be sure it's future-proof (I believe this is the decrypted and parsed cell content) * confirmation that the introduction-side will decrypt (and parse) the INTRODUCE2 cell, to avoid sending introduction point private keys over the control port (this puts slightly more load on the introduction point, but a single message compromise would only compromise that rendezvous, not all the rendezvous for that day from that introduction point) Together, these two changes would also support the "rendezvous approver" control port feature, where the handoff controller can filter requests as needed based on their content or on external factors such as load. This also might be a nice way of doing geographical load-balancing: an introduction for a European rendezvous point could be sent to a nearby European data center to perform the actual rendezvous. Alternately, it could be send to a lightly-loaded instance. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F |
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev