Re: [tor-dev] prop224: What should we do with torrc options?
On 11/24/2016 2:24 AM, Jesse V wrote: > On 11/23/2016 07:04 PM, Yawning Angel wrote: >> Our fix: "Add another command, that does essentially the same thing, >> because people picked the wrong options, then later deal with the >> fallout from people getting used to the temporary command, and crying >> when it's deprecated." >> >> I say "they should fix their code". > > This issue with incorrect implementations reminds me of the > compatibility issues that cause issues with new SSL/TLS standards. These > implementations led to compatibility workarounds that introduced > security issues that had to be eventually fixed by TLS_FALLBACK_SCSV. > > It's not our problem if their code breaks because they made incorrect > assumptions regarding the standard. The polite thing would be to submit > a patch so that Bitcoin nodes can update before we make the change. > > -- > Jesse > Right, which is why I have already submitted just now all the relevant details and I'll keep an eye that everyone is compatible with both v2 and v3 for the transition period to also maintain working configurations. Given that I filed it now, this should give sufficient time to be ready until our first release supporting v3. To be frank, the spec linked to me by teor for ADD_ONION clearly states the difference between :BEST and :RSA1024 so Yawning was right from the first place. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
On 11/23/2016 07:04 PM, Yawning Angel wrote: > Our fix: "Add another command, that does essentially the same thing, > because people picked the wrong options, then later deal with the > fallout from people getting used to the temporary command, and crying > when it's deprecated." > > I say "they should fix their code". This issue with incorrect implementations reminds me of the compatibility issues that cause issues with new SSL/TLS standards. These implementations led to compatibility workarounds that introduced security issues that had to be eventually fixed by TLS_FALLBACK_SCSV. It's not our problem if their code breaks because they made incorrect assumptions regarding the standard. The polite thing would be to submit a patch so that Bitcoin nodes can update before we make the change. -- Jesse signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
On Thu, 24 Nov 2016 11:13:06 +1100 teor wrote: > > On 24 Nov. 2016, at 11:04, Yawning Angel > > wrote: > > > > On Thu, 24 Nov 2016 01:43:15 +0200 > > s7r wrote: > >> I agree that this would be "the technical way" to do it, but real > >> world usability kind of prevents us to do it this way. The spec for > >> ADD_ONION indeed does not say that v2 hidden services will be > >> supported forever and it clearly SHOULD NOT, but it also doesn't > >> make much sense to abolish it at the first Tor release supporting > >> v3 services (because if we make ADD_ONION == v3 (best) this is > >> what we are doing). > > > > Even I don't think `BEST` should be changed to Ed25519 immediately, > > especially when the code is being stabilized. > > So I think we should have an option: > > OnionServiceCreateV3 0|1 > > Create V3 onion services by default when using HiddenServiceDir and > ADD_ONION BEST. > > Which defaults to 0 for at least the first release containing the new > code, and then defaults to 1 for at least one release, and then > is deprecated. This seems like a sensible plan to me. -- Yawning Angel pgpq2OHmTkmu_.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
> On 24 Nov. 2016, at 11:04, Yawning Angel wrote: > > On Thu, 24 Nov 2016 01:43:15 +0200 > s7r wrote: >> I agree that this would be "the technical way" to do it, but real >> world usability kind of prevents us to do it this way. The spec for >> ADD_ONION indeed does not say that v2 hidden services will be >> supported forever and it clearly SHOULD NOT, but it also doesn't make >> much sense to abolish it at the first Tor release supporting v3 >> services (because if we make ADD_ONION == v3 (best) this is what we >> are doing). > > Even I don't think `BEST` should be changed to Ed25519 immediately, > especially when the code is being stabilized. So I think we should have an option: OnionServiceCreateV3 0|1 Create V3 onion services by default when using HiddenServiceDir and ADD_ONION BEST. Which defaults to 0 for at least the first release containing the new code, and then defaults to 1 for at least one release, and then is deprecated. > ... 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
> On 24 Nov. 2016, at 10:56, s7r 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
teor wrote:
> No-one is proposing we abolish ADD_ONION with v2 services straight away.
>
> What we will do is make BEST mean v3, rather than v2.
> RSA1024 will continue to mean v2, as it always has.
>
> ADD_ONION has always had an explicit BEST option, if clients don't want
> the BEST type of key, they should ask for a specific type they are
> prepared to handle.
>
> Please read the appropriate control spec section:
> https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1446
>
>> I don't think it's productive to ask users to already support a new
>> feature upon our first release providing the said feature.
>
> This isn't what is proposed.
>
> (We are going to stop automatically creating v2 services via
> HiddenServiceDir in the first v3 release, but there will always be the
> ability to manually create a key. And that's a separate conversation.)
>
Hey, I apologize, my bad. I wasn't considering the options following
ADD_ONION, I thought it's straight forward. Sorry for this, my mistake.
Based on your explanation I agree with you and Yawning that
ADD_ONION:BEST should produce a v3 key, and ADD_ONION:RSA1024 v2.
>> To add some value on this point, I will bring into discussion a software
>> that is widely used, produces significant rendezvous traffic and is
>> important for some people:
>>
>> Bitcoin Core - latest versions detect if you use Tor and automatically
>> use ADD_ONION to create v2 services, and, important: it doesn't support
>> yet the v3 address types because of their length.
>
> Does it use ADD_ONION NEW:RSA1024 or ADD_ONION RSA1024:?
>
> Then it will be fine.
>
> Does it use ADD_ONION NEW:BEST?
>
> Then that's a client bug, and it should be fixed in the client.
>
Hey:
// Finally - now create the service
if (private_key.empty()) // No private key, generate one
private_key = "NEW:BEST";
// Request hidden service, redirect port.
// Note that the 'virtual' port doesn't have to be the same as
our internal port, but this is just a convenient
// choice. TODO; refactor the shutdown sequence some day.
_conn.Command(strprintf("ADD_ONION %s Port=%i,127.0.0.1:%i",
private_key, GetListenPort(), GetListenPort()),
boost::bind(&TorController::add_onion_cb, this, _1, _2));
whooops ;) filing a ticket so everyone is on the same page with us.
Thanks.
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
On Thu, 24 Nov 2016 01:43:15 +0200 s7r wrote: > I agree that this would be "the technical way" to do it, but real > world usability kind of prevents us to do it this way. The spec for > ADD_ONION indeed does not say that v2 hidden services will be > supported forever and it clearly SHOULD NOT, but it also doesn't make > much sense to abolish it at the first Tor release supporting v3 > services (because if we make ADD_ONION == v3 (best) this is what we > are doing). Even I don't think `BEST` should be changed to Ed25519 immediately, especially when the code is being stabilized. That is a completely orthogonal to the fact that people that have dumb limitations like: > Bitcoin Core - latest versions detect if you use Tor and automatically > use ADD_ONION to create v2 services, and, important: it doesn't > support yet the v3 address types because of their length. This way > people behind NAT running it can be better connected by accepting > incoming connections without an open port, some people don't want > their upstream provider to know they are using this app, etc. Should be using `NEW:RSA1024` explicitly. The override is there for a reason, and the key type is part of the serialized data that tor returns to you when you have it generate a key, precisely to avoid this sort of problem. Their fix: "Replace line 473 of bitcoin/torcontrol.cpp with `private_key = "NEW:RSA1024";`". Our fix: "Add another command, that does essentially the same thing, because people picked the wrong options, then later deal with the fallout from people getting used to the temporary command, and crying when it's deprecated." I say "they should fix their code". > I don't think it's productive to ask users to already support a new > feature upon our first release providing the said feature. If they aren't using existing interfaces correctly, when correct behavior has been part of the interface since support for it was added, quite frankly it's their problem. Regards, -- Yawning Angel pgpyANCyxWO1_.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
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. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
> On 24 Nov. 2016, at 10:43, s7r wrote: > > > teor wrote: How does ADD_ONION fit in? >>> >>> It's forward compatible by design, since you have to specify a key type >>> when you handle key management, and Tor gets to do whatever it wants if >>> you ask it to generate a key with the `BEST` algorithm. >>> >>> Assuming people who use it aren't explicitly asking for RSA1024, their >>> apps will magically switch to using Ed25519 automagically one day, when >>> their tor is updated. >>> >>> (People who expect `NEW:BEST` ADD_ONION-ed services to always give >>> RSA1024 based HSes, should fix their code since the spec makes no >>> guarantee that `BEST` will be RSA1024.) >> >> +1 >> >> (I've changed my opinion, adding a new command is pointless. >> People who want the old ADD_ONION behaviour where BEST produces a v2 HS >> can use an older version of Tor, until the software that makes >> incorrect assumptions is updated.) >> >> T >> > > I agree that this would be "the technical way" to do it, but real world > usability kind of prevents us to do it this way. The spec for ADD_ONION > indeed does not say that v2 hidden services will be supported forever > and it clearly SHOULD NOT, but it also doesn't make much sense to > abolish it at the first Tor release supporting v3 services (because if > we make ADD_ONION == v3 (best) this is what we are doing). No-one is proposing we abolish ADD_ONION with v2 services straight away. What we will do is make BEST mean v3, rather than v2. RSA1024 will continue to mean v2, as it always has. ADD_ONION has always had an explicit BEST option, if clients don't want the BEST type of key, they should ask for a specific type they are prepared to handle. Please read the appropriate control spec section: https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1446 > I don't think it's productive to ask users to already support a new > feature upon our first release providing the said feature. This isn't what is proposed. (We are going to stop automatically creating v2 services via HiddenServiceDir in the first v3 release, but there will always be the ability to manually create a key. And that's a separate conversation.) > To add some value on this point, I will bring into discussion a software > that is widely used, produces significant rendezvous traffic and is > important for some people: > > Bitcoin Core - latest versions detect if you use Tor and automatically > use ADD_ONION to create v2 services, and, important: it doesn't support > yet the v3 address types because of their length. Does it use ADD_ONION NEW:RSA1024 or ADD_ONION RSA1024:? Then it will be fine. Does it use ADD_ONION NEW:BEST? Then that's a client bug, and it should be fixed in the client. > ... 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
teor wrote: >>> >>> How does ADD_ONION fit in? >> >> It's forward compatible by design, since you have to specify a key type >> when you handle key management, and Tor gets to do whatever it wants if >> you ask it to generate a key with the `BEST` algorithm. >> >> Assuming people who use it aren't explicitly asking for RSA1024, their >> apps will magically switch to using Ed25519 automagically one day, when >> their tor is updated. >> >> (People who expect `NEW:BEST` ADD_ONION-ed services to always give >> RSA1024 based HSes, should fix their code since the spec makes no >> guarantee that `BEST` will be RSA1024.) > > +1 > > (I've changed my opinion, adding a new command is pointless. > People who want the old ADD_ONION behaviour where BEST produces a v2 HS > can use an older version of Tor, until the software that makes > incorrect assumptions is updated.) > > T > I agree that this would be "the technical way" to do it, but real world usability kind of prevents us to do it this way. The spec for ADD_ONION indeed does not say that v2 hidden services will be supported forever and it clearly SHOULD NOT, but it also doesn't make much sense to abolish it at the first Tor release supporting v3 services (because if we make ADD_ONION == v3 (best) this is what we are doing). I don't think it's productive to ask users to already support a new feature upon our first release providing the said feature. To add some value on this point, I will bring into discussion a software that is widely used, produces significant rendezvous traffic and is important for some people: Bitcoin Core - latest versions detect if you use Tor and automatically use ADD_ONION to create v2 services, and, important: it doesn't support yet the v3 address types because of their length. This way people behind NAT running it can be better connected by accepting incoming connections without an open port, some people don't want their upstream provider to know they are using this app, etc. Example: my Bitcoin node (working as a dual stack both on clearnet and onion) has 146 total connections to peers, out of which onion: ~# sudo -u bitnode -i bitcoin-cli getpeerinfo | grep onion | wc -l 29 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
On Thu, 24 Nov 2016 01:18:46 +0200 s7r wrote: > Yes, this looks good to me as well. As for ADD_ONION, I think we > should give the people that use it automatically for other apps a > change until they upgrade to be compatible with v3, so for the > transition period as long as v2 is supported (but not recommended) in > the network, ADD_ONION controller command will create a v2 service, > and we add another controller command: ADD_ONIONV3 that will create > v3 services. When v2 is permanently gone, we make ADD_ONION a synonym > to ADD_ONIONV3, remove the RSA1024/SHA1 code and we're all set. What. Why. Anyone right now, that explicitly wants a v2 service going forward, should use `ADD_ONION` correctly. It takes the type of key for a reason. Regards, -- Yawning Angel pgp2wVUuKfIgH.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
> On 24 Nov. 2016, at 10:18, s7r 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 tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
> On 24 Nov. 2016, at 09:00, Yawning Angel wrote: > > On Wed, 23 Nov 2016 03:12:22 +0400 > meejah wrote: > >> David Goulet writes: >> >>> 1) Once v3 is released, from that point on _no_ v2 service will be >>> allowed to be created by "tor" itself. It will always be possible >>> to do it by hand by creating an RSA key and putting it in the >>> service directory (see 3 below). >> >> +1 or +2 at least :) >> >>> Ok here it is. Please comment, improve, or propose! :) >> >> How does ADD_ONION fit in? > > It's forward compatible by design, since you have to specify a key type > when you handle key management, and Tor gets to do whatever it wants if > you ask it to generate a key with the `BEST` algorithm. > > Assuming people who use it aren't explicitly asking for RSA1024, their > apps will magically switch to using Ed25519 automagically one day, when > their tor is updated. > > (People who expect `NEW:BEST` ADD_ONION-ed services to always give > RSA1024 based HSes, should fix their code since the spec makes no > guarantee that `BEST` will be RSA1024.) +1 (I've changed my opinion, adding a new command is pointless. People who want the old ADD_ONION behaviour where BEST produces a v2 HS can use an older version of Tor, until the software that makes incorrect assumptions is updated.) 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
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. > > 1) Once v3 is released, from that point on _no_ v2 service will be allowed to >be created by "tor" itself. It will always be possible to do it by hand by >creating an RSA key and putting it in the service directory (see 3 below). > >The reasoning for this is that we really want to phase out as quickly as >possible the v2 protocol for privacy and security reasons. > Perfect. Fully agree. > 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. > 3) When tor is loading config for a service: > >if a v2 key is found that is an RSA key, we treat that service as v2, print >a deprecation warning and continue. > >if a v3 key is found, use v3, all is good. > >if no key is found, consider a new service and generate v3 (ties to 1 >above). > Great. > 4) Over time, extra option might appear and they will be ONLY for v3 unless >for force majeur security madness. > >One of those options that we want to add is this one as offline key will be >a reality with v3: > > "HiddenServiceOfflineKey 1" > >It will indicate tor to _not_ generate the master identity key and will >require the user to put the public key in the HiddenServiceDir. > > Note that with all of the above it will be possible to have one of your > application on both v2 and v3 address. Here is a snippet as an example: > > # v2 > HiddenServiceDir /srv/hs/v2 > HiddenServicePort 80 localhost:80 > > # v3 > HiddenServiceDir /srv/hs/v3 > HiddenServicePort 80 localhost:80 > > The important part here is the different directories but the port points to > the same place. > > Ok here it is. Please comment, improve, or propose! :) > > Cheers! > David > > [1] https://www.torproject.org/docs/tor-manual.html.en (see HIDDEN SERVICE > OPTIONS) > Yes, this looks good to me as well. As for ADD_ONION, I think we should give the people that use it automatically for other apps a change until they upgrade to be compatible with v3, so for the transition period as long as v2 is supported (but not recommended) in the network, ADD_ONION controller command will create a v2 service, and we add another controller command: ADD_ONIONV3 that will create v3 services. When v2 is permanently gone, we make ADD_ONION a synonym to ADD_ONIONV3, remove the RSA1024/SHA1 code and we're all set. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
On Wed, 23 Nov 2016 03:12:22 +0400 meejah wrote: > David Goulet writes: > > > 1) Once v3 is released, from that point on _no_ v2 service will be > > allowed to be created by "tor" itself. It will always be possible > > to do it by hand by creating an RSA key and putting it in the > > service directory (see 3 below). > > +1 or +2 at least :) > > > Ok here it is. Please comment, improve, or propose! :) > > How does ADD_ONION fit in? It's forward compatible by design, since you have to specify a key type when you handle key management, and Tor gets to do whatever it wants if you ask it to generate a key with the `BEST` algorithm. Assuming people who use it aren't explicitly asking for RSA1024, their apps will magically switch to using Ed25519 automagically one day, when their tor is updated. (People who expect `NEW:BEST` ADD_ONION-ed services to always give RSA1024 based HSes, should fix their code since the spec makes no guarantee that `BEST` will be RSA1024.) Regards, -- Yawning Angel pgpM1AZw5zcVy.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
> On 24 Nov. 2016, at 06:09, Jesse V wrote: > > On 11/23/2016 09:39 AM, David Goulet wrote: >> I agree with you on the fact that ADD_ONION is nice and also crucial to >> hidden >> service as well. That will be addressed with the control port implementation >> of next generation. It's still an undecided part of the engineering work >> which >> is how we are going to proceed with it. Do we change the current >> events/commands to support both v2 and v3? Do we make new events/commands for >> v3? ... (#20699) > > I suggest that we create new commands for v3. This will allow us to > officially deprecate the old APIs and its more intuitive for developers > since the distinction is clearer. It also makes it easier to maintain backwards compatibility. > This is also a golden opportunity to > change "HiddenServiceX" to "OnionServiceX" if we want to officially > transition the lingo. Yes, that's the plan. (We made the single onion service options start with HiddenService so we could change them all at once.) https://trac.torproject.org/projects/tor/ticket/17343 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Distributed RNG Research
On 11/18/2016 10:30 AM, ban...@openmailbox.org wrote: > New research on Distributed RNGs is published: "Scalable Bias-Resistant > Distributed Randomness" > > eprint.iacr.org/2016/1067 Nice! There's also https://eprint.iacr.org/2015/1015.pdf, which shows that you can extract at least 32 bits of entropy from Bitcoin every 10 minutes. I chose this generator for my Onion Name System project. -- Jesse signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
On 11/23/2016 09:39 AM, David Goulet wrote: > I agree with you on the fact that ADD_ONION is nice and also crucial to hidden > service as well. That will be addressed with the control port implementation > of next generation. It's still an undecided part of the engineering work which > is how we are going to proceed with it. Do we change the current > events/commands to support both v2 and v3? Do we make new events/commands for > v3? ... (#20699) I suggest that we create new commands for v3. This will allow us to officially deprecate the old APIs and its more intuitive for developers since the distinction is clearer. This is also a golden opportunity to change "HiddenServiceX" to "OnionServiceX" if we want to officially transition the lingo. -- Jesse signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Onionoo 3.1-1.0.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! More than five years of development [0] led to the very first release of Onionoo, which is now available here: https://dist.torproject.org/onionoo/3.1-1.0.0/ For those who haven't heard of Onionoo: Onionoo [0] is a web-based protocol to learn about currently running Tor relays and bridges. Onionoo responds to HTTP GET requests with JSON-formatted replies. As reading JSON-files is not everyones favorite, there are quite a few client applications building on Onionoo's data and providing human-readable information [0]. In case you're wondering about the version number: The version of Onionoo consists of the current protocol version [2], which is 3.1 and the software's version 1.0.0. The first Onionoo protocol was already released two years ago. With the first Onionoo release and the accompanying operating guide [3] you're just one download away from running your own Onionoo mirror. Please direct comments and questions to the metrics-team mailing list [4]. Cheers, iwakeh [0] https://gitweb.torproject.org/onionoo.git/log/?ofs=500 [1] https://onionoo.torproject.org/ [2] https://onionoo.torproject.org/protocol.html [3] see release tar-ball: INSTALL.md [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlg12wIACgkQsANAxTOj/aaXjwEAj9NWFefHYPlY9UmIR7oflh/y U/DfO0kVf/aAigyI4u0A+QF6atK+Yqw1B+E7jjOL8wMhA4sDsnsRr7KxBA7QqwVG =NQpw -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] sketch: An alternative prop224 authentication mechanism based on curve25519
Nick Mathewson writes: > [ text/plain ] > Hi! I thought I'd write this up while it was fresh in my mind. It > could be used as an alternative method to the current proposed client > authentication mechanism. We could implement both, or just this, or > just the other. > > My description here will be a bit terser than we'd want in a proper > proposal, but I wanted to share it. > > This design is based on George Kadianakis's client authentication > design; it won't make sense unless you've read it. > OK people, I have a more mature torspec branch now for your eyes and only. Please see branch `prop224_client_auth_4` in my torspec repo: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_auth_4 The changes are based on the feedback and discussion on this thread. The only real changes from `prop224_client_auth_3` is that it increases the max descriptor size to 50k, and it removes the username/password intro-level authorization. Please let me know of anything that seems off, or anything that can make the proposal more readable. Otherwise, we should merge this upstream and move forward with fixing the already merged prop224 HSDir code. Thanks! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: What should we do with torrc options?
On 23 Nov (03:12:22), meejah wrote: > David Goulet writes: > > > 1) Once v3 is released, from that point on _no_ v2 service will be allowed > > to > >be created by "tor" itself. It will always be possible to do it by hand > > by > >creating an RSA key and putting it in the service directory (see 3 > >below). > > +1 or +2 at least :) > > > Ok here it is. Please comment, improve, or propose! :) > > How does ADD_ONION fit in? > > I think the ephemeral interface is really good, and IME integrators > prefer it -- if they're already "handing secret stuff" (which seems > fairly likely, if they're aware of Tor and are integrating it in their > application) then it makes more sense for them to use this API. > > Also, it's right now extremely unlikely (and in any case very fragile) > to actually succesffully add a service to a running Tor via "SETCONF" -- > so I think anything using the control-protocol will typically prefer > ADD_ONION. If you want to use the filesystem/torrc approach, txtorcon > will always launch a new Tor instance for you (maybe this is the best > way to go anyway for "Tor-integrating applications"?) > > All that said, I'm not suggesting the torrc/"filesystem" options go > away! These are already familiar to most service operators, presumably, > and your approach sounds great! It's also really easy to support from a > controller perspective. Also, the backwards-compatibility is very nice > too. I agree with you on the fact that ADD_ONION is nice and also crucial to hidden service as well. That will be addressed with the control port implementation of next generation. It's still an undecided part of the engineering work which is how we are going to proceed with it. Do we change the current events/commands to support both v2 and v3? Do we make new events/commands for v3? ... (#20699) It's quite a big piece of work so if anyone wants to take a stab at the specification! woot!!! :) Thanks! David > > -- > meejah > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
