On Wed, Sep 30, 2015 at 05:27:28PM +0200, Tom van der Woerdt wrote:
I'd like your thoughts and comments on this proposal.
Tom
Hi Tom!
I am slowly turning back into a Tor developer. I like this proposal.
Here are some thoughts:
- The INTRODUCE event should happen independent of the value of HiddenServiceAutomaticRendezvous. From reading the proposal I thought you meant this, but then looking at your suggested patches it looks like you only deliver the event if automaticrendezvous is disabled. The controller should have the option to just observe if it wants. (In the implementation, you might want to check if there are any controllers that care about the event, before constructing the rendezvousblob.)
- We do indeed need a clearer name for INTRODUCE -- but my reason is different from the others presented. I want it clearer because in the future the *client* side could have an event when it sends its introduction cell, and that one will start out being called INTRODUCE too. So maybe HS_SERVER_INTRODUCE or something. We need to look into the future when we have events for all the various rendezvous steps, and pick a naming scheme now that won't be too terrible then.
- I also have a weak preference towards having the first Tor do the decryption -- I think George's point about the replaycache is a good one.
- I agree with Nick that we need a specification for what version "1" of the rendezvousblob format will look like. A specification that says it won't specify the core piece of the design is not cool. :)
If no controllers are present, the introduction cell should be dropped
So if the controller dies for some reason, the onion service will now quietly ignore all introduction requests. That's a bit sad. But I think it's still the best design -- and controllers that setconf AutomaticRendezvous to 0 can use the TAKEOWNERSHIP command to make sure Tor exits rather than remains silently useless.
Let's take an example where a client (Alice) tries to contact Bob's hidden service. To do this, Bob follows the normal hidden service specification, except he sets up ten servers to do this. One of these publishes the descriptor, the others have this desabled.
Do we also want a way to tell an onion service to not bother establishing or maintaining intro points? Maybe via letting HiddenServiceNumIntroductionPoints be 0? (I recommend not letting this idea block any of the rest of the implementation or deployment. :)
--Roger