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

[teor <teor2345@xxxxxxxxx>]

> On 24 Nov. 2016, at 10:56, s7r <s7r@xxxxxxxxxx> wrote:
> 
> 
> 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

Which my proposal avoids, by re-using the v2 keys for v3 services.

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

The v3 keys derived from the existing v2 keys would have the same
entropy as those keys: 16 bytes (REND_DESC_COOKIE_LEN).

Yes, this is inferior to the ~31 bytes of entropy in an ed25519 key.

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



_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev