[tor-dev] prop224: What should we do with torrc options?

[teor]

> 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[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.
>> ...
> 
>> 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
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

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------