Hi,
David Goulet wrote:
On 24 Nov (11:13:06), teor wrote:
On 24 Nov. 2016, at 11:04, Yawning Angel yawning@schwanenlied.me wrote:
On Thu, 24 Nov 2016 01:43:15 +0200 s7r s7r@sky-ip.org wrote:
I agree that this would be "the technical way" to do it, but real world usability kind of prevents us to do it this way. The spec for ADD_ONION indeed does not say that v2 hidden services will be supported forever and it clearly SHOULD NOT, but it also doesn't make much sense to abolish it at the first Tor release supporting v3 services (because if we make ADD_ONION == v3 (best) this is what we are doing).
Even I don't think `BEST` should be changed to Ed25519 immediately, especially when the code is being stabilized.
So I think we should have an option:
OnionServiceCreateV3 0|1
Few things why I'm not too keen with this even though it could actually be very useful... I'll outline the potential issues here with such an option but unfortunately I don't have a perfect solution in the end. My main concern is not really an easy or intuitive way for the user to start using v3 service but rather when the users will start using it, the network MUST be ready for it which makes things a bit more complicated to do properly I believe.
Considering a torrc option such as "OnionServiceCreateV3 0|1":
- This is extremely non intuitive to any operator even power users. The concept of "v3" is something that very few people will understand what it's actually is. Even if we go with "OnionServiceEpicNextMoreSecureGeneration 1", we are creating two classes of onion service that will make things more confusing for the user with the question of "which one should I use?". Also see 3 below for more confusion.
I agree. We should avoid adding new torrc options with different confusing and potentially expiring versions at the end. This is why I suggested, for v3 ed25519 key based authenticated clients we will not add a torrc option, but instead we change the auth-type for HiddenServiceAuthorizeClient, example:
HiddenServiceAuthorizeClient pubkey /var/lib/tor/hs-name/authclient.dat
Where Tor will know to interpret 'pubkey' for only v3 obviously.
- It also means we create an option that will get deprecated once v2 is phased out so we are adding a "temporary" option for users to "keep creating v2 addresses" but then will be useless and we'll deprecate and get a whole lot confusing if for instance v4 or v5 happens in the next years for X reasons (unlikely but not impossible).
This is very correct.
The current plan so far is to add a consensus parameter that will control the switch for client and service to start using prop224. And every relay out there that will run a tor supporting the v3 protocol (HSDir, IP, RP) will speak the protocol no matter what. So then we can decide when the network is mature enough for client/service to start talking actively that protocol.
That switch will also be an opportunity for us to remove v0 and v1 support as well from tor making that event "The Big Onion Service Switch" or for short "The BOSS (tm)" :P.
HOWEVER, the hard part here is getting that consensus param information about the state of prop224 _before_ configuring your HS.... it's doable but will weirdly make a specific tor version bootstrap HS much slower as they'll have to wait for the consensus to be downloaded.... maybe there is a better way?
Here is an idea, we could rely on a tor version for enabling the feature instead that is we release client/service support when and only when the network is mature so then there will be no confusion, you run version X, you get v3, period, the network is ready. That is again not ideal as we then delay this important new feature by some unknown chunks of 6 months... but at least we have some assurance that it's ready.
We can ship the code in let's say 031 but make tor only use it in 032 for instance.
Thoughts?
David
teor's previous post on this thread is a good idea, to use HiddenServiceVersion. I am afraid there's no way to do it without a consensus param and little more bootstrap needed before HS is created for the benefit of not delaying the feature by some unknown time.
The HiddenServiceVersion could have priorities like:
0: value from torrc 2: default one for the Tor version, which is: a) whatever the instance is running, if it already has a HS key in the configured HiddenServiceDir. b) the consensus param c) if no consensus param, 2, until a specific version when we see the network is ready for v3. This version will have the default set to 3.
Since this version, v2 cannot be created any more nor existing keys for v2 will work any more - we have all the reasons to push for faster v3 adoption.
It becomes quite complicated if we want to allow people hosting v2 and v3 simultaneously on the same instance, so we should think carefully if we want to allow this or not.