> On 24 Nov. 2016, at 10:18, s7r <[email protected]> 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 ------------------------------------------------------------------------ _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
