On 24 Nov. 2016, at 10:18, s7r s7r@sky-ip.org wrote:
Hello David,
David Goulet wrote:
Hi everyone!
We are soon at the stage of implementing the service part of proposal 224 (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing here ticket #18054.
In a nutshell, we need to figure out the interface for the torrc file[1]. We currently have some options to configure an hidden service and the question is now how do we proceed on using those for next version?
Instead of listing all options and going in an endless loop of possibilities, I'll outline what we've discussed so far between some of us. In the following, "v2" is current hidden service and "v3" is the next generation detailed in prop224. ...
- All the current torrc options will be kept for v3 as they all apply in
terms of format. (One exception might be the client authorization.)
Very good. We can add a new torrc option for ed25519 key based authentication for clients (v3) so the current HiddenServiceAuthorizeClient (v2) will not break old torrc's until everyone upgrades.
However, we could just add an auth-type value after HiddenServiceAuthorizeClient that will only work for v3. For example:
HiddenServiceAuthorizeClient pubkey client-name,client-name,client-name,...
It's obvious where 'pubkey' comes from, but it can be changed to anything. This way we preserve the option that it's already common for users (HiddenServiceAuthorizeClient), we maintain compatibility of torrcs during transition period and also have the same option in the future when we are fully migrated to v3.
This is perfectly fine, since we do not use any auth method that works on v2 to v3 (which I am also super happy with). We also don't restrict ourselves from the possibility to add new auth-types for v3 in the future, should we need them.
This means that people who upgrade to v3 services will need to redistribute all their client auth keys. This could be a lot of work, particularly if the out-of-band channel is manual, or there are a large number of users.
Here's an alternative proposal:
Tor accepts v2 HiddenServiceAuthorizeClient and HidServAuth for v3 services, then feeds the auth-cookie into a key derivation function to produce an ed25519 private key. This key is used for authentication as specified.
I don't think this is worth the extra coding effort - I think we are better to focus on getting people to upgrade, and designing the new options to be easy to use.
But I could be convinced if a hidden service operator who uses client authentication says it would take a lot of effort to re-issue client keys.
(That said, I assume operators would re-issue keys the same way they send the updated v3 onion address.)
...
T