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

[s7r]

teor wrote:
> 
>>
>> 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.
> 
This is not specified anywhere until now, my suggestion was based on the
current form of the proposals. For v3 we only use ed25519 key based
authentication, and if we use:

HiddenServiceAuthroizeClient pubkey client1,client2

Tor will use this only for v3 of course, while:

HiddenServiceAuthorizeClient basic client1,client2 will only be used for v2.

If an user upgrades to v3, it has no other but to generate the new
authentication credentials (keys) for clients, regardless of the torrc
option we use.

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

No, no, it is not worth it *at all*. The biggest headache is in
distributing the private keys out of band to authorized clients, not
their generation (generation is done by Tor automatically, in few
seconds, based on just one line with the client names). And we have no
way to skip the distribution phase, better focus to make the key
management as simple as possible rather than coding a derivation
function that (maybe) provides a false sense of security if the
passphrases have low entropy.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161124/90f96ece/attachment.sig>