[tor-dev] prop224: What should we do with torrc options?
teor2345 at gmail.com
Wed Nov 23 23:33:57 UTC 2016
> On 24 Nov. 2016, at 10:18, s7r <s7r at 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. 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
>> 2) 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
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
(That said, I assume operators would re-issue keys the same way they
send the updated v3 onion address.)
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
xmpp: teor at torproject dot org
More information about the tor-dev