Hello,
I inline a proposal for Direct Onion Services. It's heavily based on the "encrypted services" proposal of Roger, but I refined it, made it more proposaley and enabled a few more optimizations. You can find the original piece here: https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted...
Feedback would be greatly appreciated.
Here are some specific points that I would like help with:
- Should we require a specially compiled version of Tor to enable this feature? Like we do for tor2web mode? In this proposal, I didn't require any special compilation flags. I don't have strong opinions here.
- We really really need a better name for this feature. I decided to go with "Direct Onion Services" which is the one that the NRL people suggested here: https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html I'm not super happy with it, but I can't think of better ones myself. Here are some candidates: 1 Way Anonymous Hidden Services Fast Onion Service Short-circuited Onion Services Fast-but-not-hidden Services
- We also need a better torrc option. If the name of this feature does not portray its dangers, then the torrc option should be a bit terrifying. That's why I went 'DangerousDirectOnionService' which I actually don't like at all. BTW, it's unclear whether this mailing list is the best place to brainstorm for names.
Here goes proposal:
----
Filename: 244-direct-services.txt Title: Direct Onion Services: Fast-but-not-hidden services Author: Roger Dingledine, George Kadianakis Created: 2011-01-12 Status: Draft
1. Motivation
Hidden services can cover multiple use cases and threat models. They offer server-side anonymity by default because that's the most common use case, but there also hidden service users who don't really need service-side anonymity.
This proposal aims to satisfy those users by introducing an optional opt-in feature that *sacrifices server-side anonymity* *for better performance*. Client-side anonymity will still be preserved as normal.
Here are some use cases that this idea addresses:
1) Indymedia wants to run an exit enclave that provides end-to-end authentication and encryption. They tried running an exit relay that just exits to themselves (#800) but * it handles lots of other traffic too since it's a relay * exit enclaves don't actually work consistently, because the first connection from the user doesn't realize it should use the exit enclave.
2) Wikileaks uses Tor hidden services not to hide their service, but because the hidden service address provides a type of usability we didn't think much about: unlike a more normal address, a Tor hidden service address either works (meaning you get your end-to-end authentication and encryption) or it fails hard. With a hidden service address there's no way a user could accidentally submit their documents to Wikileaks without using Tor, but with normal Tor it's possible.
3) The Freenode IRC network wants to provide end-to-end encryption and authentication to its users, a) to handle the fact that the IRC protocol doesn't really provide much of that by default, and b) to funnel all their Tor users into a single location so they can handle the anonymous users better. They don't mind the fact that their service is hidden, but they'd rather have better performance for their users given the choice.
As a side-effect, by optimizing for performance in this feature, it allows us to lean more heavily towards security decisions for regular onion services.
2. Design
We suggest the following changes to be implemented:
i. Add a way in the torrc file to specify that this service wants to be an encrypted service rather than a hidden service. [TORRC]
ii. An encrypted service SHOULD establish 1-hop circuits to its introduction points. [ONEHOP]
iii. An encrypted service SHOULD establish 1-hop circuits to rendezvous points [ONEHOP].
iv. An encrypted service MAY NOT use static guard nodes [NOGUARDS].
More information about these steps can be found in the next section.
3. Specification
3.1. Torrc configuration parameter [TORRC]
To enable this optional feature, we introduce the boolean DangerousDirectOnionService torrc option. The option MUST be *disabled by default*.
Because of the grave consequences of misconfiguration here, we have prepended the torrc option with 'Dangerous'. Furthermore, Tor MUST issue a startup warning message to operators of the hidden service if this feature is enabled.
3.2. One-hop circuits [ONEHOP]
When in this mode, the onion service establishes 1-hop circuits to introduction and rendezvous points. The onion service SHOULD also ignore cannibalizable 3-hop circuits when creating such circuits.
This looks like this for the rendezvous point case:
|direct onion service| -> RP <- client middle <- client guard <- |client|
This change allows greater speeds when establishing a hidden service circuit and reduces round-trip times. As a side-effect, busy onion services with this feature cause less damage to the rest of the network, since their traffic gets passed around less.
3.3. Disable guard nodes [NOGUARDS]
Entry guards are a security measure against Sybil attacks. Unfortunately, they also act as the bottleneck of busy hidden services and overload those Tor relays.
This proposal suggests disabling the entry guard feature entirely when this mode is enabled. This allows the hidden service to split its traffic out to multiple relays on the network.
4. Security implications
There's a possible second-order effect here since both encrypted services and hidden services will have foo.onion addresses and it's not clear based on the address whether the service will be hidden -- if *some* .onion addresses are easy to track down, are we encouraging adversaries to attack all rendezvous points just in case?
5. Future
Here are some thoughts on things we could look in the future to further optimize performance when this mode is enabled:
- We should look whether we can optimize further the preemptive circuits that Tor makes as a hidden service.
- We could also make hidden services determine the number of introduction points based on their popularity, to allow greater load balancing. This has the potential for leaking the popularity of hidden services (#4862), but maybe this is not a concern when this mode is enabled.
- For this mode, we could look into alternative designs where a rendezvous step is not needed, and the traffic gets routed through the introduction points (as in Valet nodes [0]).
On 09 Apr (21:58:49), George Kadianakis wrote:
Hello,
I inline a proposal for Direct Onion Services. It's heavily based on the "encrypted services" proposal of Roger, but I refined it, made it more proposaley and enabled a few more optimizations. You can find the original piece here: https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted...
Feedback would be greatly appreciated.
First thanks for that! Really useful stuff.
Here are some specific points that I would like help with:
- Should we require a specially compiled version of Tor to enable this feature? Like we do for tor2web mode? In this proposal, I didn't require any special compilation flags. I don't have strong opinions here.
IMO, I'm not sure this is useful. This feature requires prior knowledge of the HS operator to know what's a "Direct Onion Service" and decide that she wants that for her service. Thus, a torrc option seems enough. I don't see any reasons for this option that will limit deployment.
- We really really need a better name for this feature. I decided to go with "Direct Onion Services" which is the one that the NRL people suggested here: https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html I'm not super happy with it, but I can't think of better ones myself. Here are some candidates: 1 Way Anonymous Hidden Services Fast Onion Service Short-circuited Onion Services Fast-but-not-hidden Services
"Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like it because it describes pretty much what it is and the acronym is FOSS. :)
- We also need a better torrc option. If the name of this feature does not portray its dangers, then the torrc option should be a bit terrifying. That's why I went 'DangerousDirectOnionService' which I actually don't like at all. BTW, it's unclear whether this mailing list is the best place to brainstorm for names.
This one depends on the name quite heavily but I don't think we should have a scary name. Scary name seems to me they will simply bring more questions without context of the actual feature. What is "Dangerous" about this, why is it in Tor at all?... This could simply be resolved by clear and thorough documentation of the risks/benefits of the options.
For instance, we could *not* put it in the default torrc file and thus will only be in the man page with *good* documentation. Like you said also in the proposal, a big warning is very important at boot.
If it's off by default and not present in the torrc file, there are no reasons why someone would enable this just because it's says "DirectOnionServiceEnable". (Ok I might be an optimist but still, we are not that responsible for reckless HS operator ;)
[snip]
3.2. One-hop circuits [ONEHOP]
When in this mode, the onion service establishes 1-hop circuits to introduction and rendezvous points. The onion service SHOULD also ignore cannibalizable 3-hop circuits when creating such circuits.
This looks like this for the rendezvous point case:
|direct onion service| -> RP <- client middle <- client guard <- |client|This change allows greater speeds when establishing a hidden service circuit and reduces round-trip times. As a side-effect, busy onion services with this feature cause less damage to the rest of the network, since their traffic gets passed around less.
Would it be possible to drop the rendezvous part where the client could simply connect to the IP and then the circuit back to the HS would be used? (Though that would require that the client knows the HS it's trying to reach is a Direct Onion Service, could be mention in the descriptor?...)
This idea ^ is mention in the Future section but why not using it? Too much of a change? Unknown anonymity implications?
Cheers! David
Optimizations like these are really what help make onion services performant. With the right architecture I think they can be much faster and more secure than regular non-onion (i.e. exit-node routed) sites. A couple questions/comments:
- What is the exact need for introduction points here at all? The onion service can just act as it's own introduction point(s), advertising its IPs to the HSDirs. They're possibly useful for load-balancing, but that can be achieved easier without these additional, third-party relays. - Removing rendezvous nodes is a bigger change to the protocol, but would be very useful. Why not enable the client to just directly establish circuit(s) directly to the onion service? As David pointed out, this would probably be implemented most cleanly with a tag in the HSDir descriptor (this would conveniently identify the service as non-hidden, whether that's a good or bad thing...)
————————— Jacob H. Haven – https://jhaven.me/ https://jhaven.me/ jacob@jhaven.me jacob@cloudflare.com jhaven@cs.stanford.edu +1-(949)-415-6469
On Thu, Apr 9, 2015 at 1:17 PM, David Goulet dgoulet@ev0ke.net wrote:
On 09 Apr (21:58:49), George Kadianakis wrote:
Hello,
I inline a proposal for Direct Onion Services. It's heavily based on the "encrypted services" proposal of Roger, but I refined it, made it more proposaley and enabled a few more optimizations. You can find the original piece here:
https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted...
Feedback would be greatly appreciated.
First thanks for that! Really useful stuff.
Here are some specific points that I would like help with:
- Should we require a specially compiled version of Tor to enable this feature? Like we do for tor2web mode? In this proposal, I didn't require any special compilation flags. I don't have strong opinions here.
IMO, I'm not sure this is useful. This feature requires prior knowledge of the HS operator to know what's a "Direct Onion Service" and decide that she wants that for her service. Thus, a torrc option seems enough. I don't see any reasons for this option that will limit deployment.
- We really really need a better name for this feature. I decided to go with "Direct Onion Services" which is the one that the NRL people suggested here:
https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html
I'm not super happy with it, but I can't think of better ones myself. Here are some candidates: 1 Way Anonymous Hidden Services Fast Onion Service Short-circuited Onion Services Fast-but-not-hidden Services
"Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like it because it describes pretty much what it is and the acronym is FOSS. :)
- We also need a better torrc option. If the name of this feature does not portray its dangers, then the torrc option should be a bit terrifying. That's why I went 'DangerousDirectOnionService' which I actually don't like at all. BTW, it's unclear whether this mailing list is the best place to brainstorm for names.
This one depends on the name quite heavily but I don't think we should have a scary name. Scary name seems to me they will simply bring more questions without context of the actual feature. What is "Dangerous" about this, why is it in Tor at all?... This could simply be resolved by clear and thorough documentation of the risks/benefits of the options.
For instance, we could *not* put it in the default torrc file and thus will only be in the man page with *good* documentation. Like you said also in the proposal, a big warning is very important at boot.
If it's off by default and not present in the torrc file, there are no reasons why someone would enable this just because it's says "DirectOnionServiceEnable". (Ok I might be an optimist but still, we are not that responsible for reckless HS operator ;)
[snip]
3.2. One-hop circuits [ONEHOP]
When in this mode, the onion service establishes 1-hop circuits to introduction and rendezvous points. The onion service SHOULD also ignore cannibalizable 3-hop circuits when creating such circuits.
This looks like this for the rendezvous point case:
|direct onion service| -> RP <- client middle <- client guard <-|client|
This change allows greater speeds when establishing a hidden service circuit and reduces round-trip times. As a side-effect, busy onion services with this feature cause less damage to the rest of the network, since their traffic gets passed around less.
Would it be possible to drop the rendezvous part where the client could simply connect to the IP and then the circuit back to the HS would be used? (Though that would require that the client knows the HS it's trying to reach is a Direct Onion Service, could be mention in the descriptor?...)
This idea ^ is mention in the Future section but why not using it? Too much of a change? Unknown anonymity implications?
Cheers! David
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
"Jacob H. Haven" jacob@jhaven.me writes:
Optimizations like these are really what help make onion services performant. With the right architecture I think they can be much faster and more secure than regular non-onion (i.e. exit-node routed) sites. A couple questions/comments:
- What is the exact need for introduction points here at all? The onion
service can just act as it's own introduction point(s), advertising its IPs to the HSDirs. They're possibly useful for load-balancing, but that can be achieved easier without these additional, third-party relays.
- Removing rendezvous nodes is a bigger change to the protocol, but
would be very useful. Why not enable the client to just directly establish circuit(s) directly to the onion service? As David pointed out, this would probably be implemented most cleanly with a tag in the HSDir descriptor (this would conveniently identify the service as non-hidden, whether that's a good or bad thing...)
i think both of these ideas are technically possible, and they would indeed improve performance for this use case. Both of them would require some non-trivial engineering work to alter the HS code to be able to do all this stuff, but it might be worth it.
One negative aspect of the above suggestions, is that if hidden services only listen for connections, then they lose their NAT-punching abilities. But I bet that this is not a problem for some use cases that would appreciate the corresponding performance boost. Theoretically, the above optimizations could also be optional.
We should think more.
Thanks for the feedback!
On Apr 10, 2015, at 1:58 PM, George Kadianakis desnacked@riseup.net wrote: "Jacob H. Haven" jacob@jhaven.me writes:
[…deletia...]
Hi All,
I’m actually drafting a diff regards the sorts of thing where you’re discussing nomenclature; but I am new to the Tor codebase and would love having someone (and, perhaps, and IRC forum?) with whom/where I could chat/ask about which-bits-do-what?
Work in progress at http://pastebin.com/Pza1uyfm http://pastebin.com/Pza1uyfm - but this is all scratch, very incomplete, and predates this discussion.
I am working from the position that a “direct” onion (for the moment I’ve been using the work “brazen” - opposing “hidden” - but “direct” is more attractively mundane) does not need triple-hop circuits for everything. I am starting to get a handle on which code sets up the outbound links to the IP and RP, but I would really love to bounce some ideas off folks who have more experience of the code.
-a
— Alec Muffett Security Infrastructure Facebook Engineering London
Alec Muffett alecm@fb.com writes:
On Apr 10, 2015, at 1:58 PM, George Kadianakis desnacked@riseup.net wrote: "Jacob H. Haven" jacob@jhaven.me writes:
[…deletia...]
Hi All,
I’m actually drafting a diff regards the sorts of thing where you’re discussing nomenclature; but I am new to the Tor codebase and would love having someone (and, perhaps, and IRC forum?) with whom/where I could chat/ask about which-bits-do-what?
Thanks for the code.
Feel free to ask for help at #tor-dev @ OFTC.
Work in progress at http://pastebin.com/Pza1uyfm http://pastebin.com/Pza1uyfm - but this is all scratch, very incomplete, and predates this discussion.
I am working from the position that a “direct” onion (for the moment I’ve been using the work “brazen” - opposing “hidden” - but “direct” is more attractively mundane) does not need triple-hop circuits for everything. I am starting to get a handle on which code sets up the outbound links to the IP and RP, but I would really love to bounce some ideas off folks who have more experience of the code.
-a— Alec Muffett Security Infrastructure Facebook Engineering London
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Alec Muffett alecm@fb.com writes:
On Apr 10, 2015, at 1:58 PM, George Kadianakis desnacked@riseup.net wrote: "Jacob H. Haven" jacob@jhaven.me writes:
[…deletia...]
Hi All,
I’m actually drafting a diff regards the sorts of thing where you’re discussing nomenclature; but I am new to the Tor codebase and would love having someone (and, perhaps, and IRC forum?) with whom/where I could chat/ask about which-bits-do-what?
Work in progress at http://pastebin.com/Pza1uyfm http://pastebin.com/Pza1uyfm - but this is all scratch, very incomplete, and predates this discussion.
FWIW, I noticed that in your code, you also use 1-hop circuits when publish hidden service descriptors. This didn't seem like a big performance improvement to me when I was writing the propoasl, but if more people like it we can add it to the proposal.
On Apr 10, 2015, at 3:46 PM, George Kadianakis desnacked@riseup.net wrote:
FWIW, I noticed that in your code, you also use 1-hop circuits when publish hidden service descriptors. This didn't seem like a big performance improvement to me when I was writing the propoasl, but if more people like it we can add it to the proposal.
Absolutely. That was simply one of the easier targets to hit. :-)
I think that my next goal should be to review all circuit setups that are labelled CIRCUIT_PURPOSE_S_* - to look for which ones are being used to create the RP and IP links, and knock them down to one-hop.
That seems to be primarily rendservice.c and circuituse.c, but (to repeat) I am new at this and haven’t swallowed the codebase yet. :-)
— Alec Muffett Security Infrastructure Facebook Engineering London
Alec Muffett alecm@fb.com writes:
On Apr 10, 2015, at 1:58 PM, George Kadianakis desnacked@riseup.net wrote: "Jacob H. Haven" jacob@jhaven.me writes:
[…deletia...]
Hi All,
I’m actually drafting a diff regards the sorts of thing where you’re discussing nomenclature; but I am new to the Tor codebase and would love having someone (and, perhaps, and IRC forum?) with whom/where I could chat/ask about which-bits-do-what?
Work in progress at http://pastebin.com/Pza1uyfm http://pastebin.com/Pza1uyfm - but this is all scratch, very incomplete, and predates this discussion.
Also, the trac ticket for this feature is at:
https://trac.torproject.org/projects/tor/ticket/2555
If you make any progress, feel free to link to a git branch on that ticket. And if you need any specific help, don't forget to ask.
On 10 April 2015 at 07:58, George Kadianakis desnacked@riseup.net wrote:
One negative aspect of the above suggestions, is that if hidden services only listen for connections, then they lose their NAT-punching abilities. But I bet that this is not a problem for some use cases that would appreciate the corresponding performance boost. Theoretically, the above optimizations could also be optional.
We should think more.
I wobble back and forth on NAT-Punching for DOS (Direct Onion Services ;) ).
On one hand it's awesome to not have to worry about NAT. On the other, if you're doing to run a DOS, presumably you are capable enough to either traverse it or not have to worry about it?
Ultimately, I think I fall onto the side of wanting to keep the NAT-punching present. As we support more use cases for OSes (Onion Services ;) ) we will probably want to support people behind NATs but willing to compromise anonymity for performance. For example, I could easily envision someone being the DOS in an audio or video chat and being behind a NAT. The DOS end helps boost the performance, the client gets anonymity, everyone gets end-to-end protection.
The difference between a DOS connecting to an IP and a DOS _being_ the IP seems small, as it's only used for connection setup. Obviously being the IP would be faster... perhaps the DOS could choose IPs that (it believes) it has a low latency connection to? (If that would be feasible with the information the daemon has available to it?)
On 9 April 2015 at 22:33, Jacob H. Haven jacob@jhaven.me wrote:
Removing rendezvous nodes is a bigger change to the protocol, but would be very useful. Why not enable the client to just directly establish circuit(s) directly to the onion service? As David pointed out, this would probably be implemented most cleanly with a tag in the HSDir descriptor (this would conveniently identify the service as non-hidden, whether that's a good or bad thing...)
|direct onion service| -> RP <- client middle <- client guard <- |client|
If the RP is removed and the client makes a "direct connection" to the DOS, the client is using a two-hop circuit, not a three-hop, right? If it's a three-hop circuit, it's no different (performance-wise) than using a RP, right?
Another thought. If the DOS makes a direct connection to the HSDir for descriptor publishing the HSDir will be able to (passively) enumerate which HSes are DOSes, right? This seems like it would be something we would want to prevent. (Well, at least require the HSDir to go perform an active fingerprint to learn this information.) The use of three-hop circuits to publish this information is not strenuous either.
-tom
David Goulet dgoulet@ev0ke.net writes:
On 09 Apr (21:58:49), George Kadianakis wrote:
Hello,
I inline a proposal for Direct Onion Services. It's heavily based on the "encrypted services" proposal of Roger, but I refined it, made it more proposaley and enabled a few more optimizations. You can find the original piece here: https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted...
Feedback would be greatly appreciated.
First thanks for that! Really useful stuff.
Here are some specific points that I would like help with:
- Should we require a specially compiled version of Tor to enable this feature? Like we do for tor2web mode? In this proposal, I didn't require any special compilation flags. I don't have strong opinions here.
IMO, I'm not sure this is useful. This feature requires prior knowledge of the HS operator to know what's a "Direct Onion Service" and decide that she wants that for her service. Thus, a torrc option seems enough. I don't see any reasons for this option that will limit deployment.
Yes, I also feel the same.
My main fear is sample torrc's that are being posted around the net and people just copy-paste them into their box: someone might not notice the DirectOnionServiceEnable option.
- We really really need a better name for this feature. I decided to go with "Direct Onion Services" which is the one that the NRL people suggested here: https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html I'm not super happy with it, but I can't think of better ones myself. Here are some candidates: 1 Way Anonymous Hidden Services Fast Onion Service Short-circuited Onion Services Fast-but-not-hidden Services
"Fast Onion-Space Service" was proposed by pfmbot on #tor-dev. I like it because it describes pretty much what it is and the acronym is FOSS. :)
It's not clear to me why acronym collisions are a plus :)
- We also need a better torrc option. If the name of this feature does not portray its dangers, then the torrc option should be a bit terrifying. That's why I went 'DangerousDirectOnionService' which I actually don't like at all. BTW, it's unclear whether this mailing list is the best place to brainstorm for names.
This one depends on the name quite heavily but I don't think we should have a scary name. Scary name seems to me they will simply bring more questions without context of the actual feature. What is "Dangerous" about this, why is it in Tor at all?... This could simply be resolved by clear and thorough documentation of the risks/benefits of the options.
For instance, we could *not* put it in the default torrc file and thus will only be in the man page with *good* documentation. Like you said also in the proposal, a big warning is very important at boot.
If it's off by default and not present in the torrc file, there are no reasons why someone would enable this just because it's says "DirectOnionServiceEnable". (Ok I might be an optimist but still, we are not that responsible for reckless HS operator ;)
Yes, I agree that the 'Dangerous' prefix is stupid. I think I'm OK with changing the proposal to use 'DirectOnionServiceEnable' but I would prefer if it's a bit more alarming.
[snip]
3.2. One-hop circuits [ONEHOP]
When in this mode, the onion service establishes 1-hop circuits to introduction and rendezvous points. The onion service SHOULD also ignore cannibalizable 3-hop circuits when creating such circuits.
This looks like this for the rendezvous point case:
|direct onion service| -> RP <- client middle <- client guard <- |client|This change allows greater speeds when establishing a hidden service circuit and reduces round-trip times. As a side-effect, busy onion services with this feature cause less damage to the rest of the network, since their traffic gets passed around less.
Would it be possible to drop the rendezvous part where the client could simply connect to the IP and then the circuit back to the HS would be used? (Though that would require that the client knows the HS it's trying to reach is a Direct Onion Service, could be mention in the descriptor?...)
I think that's indeed possible, but would require multiplexing multiple client connections on a single IP circuit, which Tor cannot do at the moment AFAIK. It is my understanding that it's not an easy change, but I'm pretty sure that I2P and other projects are doing it, so we could in theory take a look at how those guys do it.
Just a minor point, mainly due to the increased intent of making things clear for journalists, politicians, and haters that like to cherry-pick things they don't understand...
Try to stay away from DOS and DDOS. For example, DangerousDirectOnionService could be shortened to DDOS in simple conversation, which would just present stupid problems and confusion, similar to the drive to change "hidden services" to "onion services".
Q: "Hey I'm a newbie, how can I setup a DDOS?" A: "Oh it's easy, a few configuration changes and you can DDOS away!"
Again... it's a minor point. But worth considering given the types of publicity Tor receives IMHO.
Half in jest, half serious, how about Peeled Onion Service? As this proposal is intended to peel away certain features... It clearly indicates that though it is an Onion Service, it is not a full fledged Onion Service with all the bells and whistles - they were peeled away!
Matt Speak Freely
On Fri, 10 Apr 2015 13:59:05 +0000 Speak Freely when2plus2is5@riseup.net wrote:
Half in jest, half serious, how about Peeled Onion Service? As this proposal is intended to peel away certain features... It clearly indicates that though it is an Onion Service, it is not a full fledged Onion Service with all the bells and whistles - they were peeled away!
I think that is good and could also be backronymed into "Public Onion Service". That would mean we'd have "Hidden Onion Services" and "Public Onion Services" and the "Dangerous" part could be omitted as it would be obvious what the dangers were.
Sincerely,
Malte
Thanks George!
On 04/09/2015 08:58 PM, George Kadianakis wrote:
- We really really need a better name for this feature. I decided to go with "Direct Onion Services" which is the one [...]
Why not simply "onion service"?
On Mon, Apr 20, 2015 at 12:04:24AM +0200, Moritz Bartl wrote:
Thanks George!
On 04/09/2015 08:58 PM, George Kadianakis wrote:
- We really really need a better name for this feature. I decided to go with "Direct Onion Services" which is the one [...]
Why not simply "onion service"?
Because we have already started using "onion service" to cover what we previously called "hidden services" until we realized that, among other things, that term is misleadingly narrow concerning the benefits such services provide. Cf. e.g., "Genuine Onion" http://www.nrl.navy.mil/itd/chacs/syverson-genuine-onion-simple-fast-flexibl...
My latest thinking about the terminology is that we should call them something like "client side onion service" (CSOS, suggested pronunciation C-sauce). All these terms seem to have limitations of one form or another, and this is no exception. This is long when compared to "hidden service" but "CSOS" is not longer to say the "HS". See the comments about pronouncability earlier in this thread. We could go with "client protecting onion service" but that doesn't differentiate it from ordinary onion services, which also protect clients. "Client only onion service" or "client oriented onion service" does that (either would be COOS, which is nicely one syllable---rhymes with 'loose'). We could use "clientside onion service" or "COS", which could be pronounced see-oh-ess or simply cuz. This would be as pronounceable as COOS but isn't as direct in connotation IMO.)
An advantage of using 'side' in the name is that this can generalize to the obviously complementary server side onion service (SSOS), both of which are onesided onion services (OSOS). Note that Tor2Web effectively converts ordinary two-sided onion services to SSOS. Most of this probably won't see much use unless someone writes a bunch of papers about them or some serverside use takes off. But I think the one we're talking primarily about, CSOS or COS, would. COOS would also complement "server oriented/only onion service" (SOOS, in honor of Theo Geisel ;>) but the one sided generalization becomes something like "one side only onion service" (OSOOS). Fortunately, as I said, I don't think we actually need such a term for regular use.
Of these I currently think COOS comes closest to conveying what we want and balancing out the various goals. And I lean towards the 'oriented' rather than 'only' de-acronymization.
aloha, Paul
Why not simply "onion service"?
Because we have already started using "onion service" to cover what we previously called "hidden services”
Right.
My latest thinking about the terminology is that we should call them something like "client side onion service" (CSOS, suggested pronunciation C-sauce).
These suggestions are too long, in my opinion, and a short acronym cannot substitute for a short name. Of primary importance, I think, is that the name be easy to use and is meaningful. I like the [modifier]+"onion service” approach, which can be further shortened to [modifier]+”service” when the onion context is clear. This already works for “hidden service”, which we can more clearly refer to using “hidden onion service”. Some options following this pattern are 1. fast onion service 2. exposed onion service 3. direct onion service 4. peeled onion service 5. bare onion service
I’m beginning to like “exposed onion service”. It makes clear the important property that the service is not hidden, it is easy to use, and it has a usable acronym (EOS or ES).
Aaron
Following on Aaron's suggestion, and further pushing my own wee agenda, what about PS? it works because even if someone confused the acronym for something else, it still works. And it matches well with HS/OS. - Public (Onion) Service - Peeled (Onion) Service - Pseudo (Onion) Service <-- I like this as well, for various reasons
Now,
- exposed onion service, in my mind, would lead to people thinking the connection is in no way secure, because it is "exposed." It definitely does have the antonym of "hidden" built in, though. Escaping the "dark web" connotations is good, but this may lead to the wrong understanding by a small but loud group of people. I can fully envision some special people running around on blogs, mailing lists, etc, telling the whole world to avoid "'exposed onion services' because the NSA/CIA/GCHQ/CSIS/DARPA forced the Tor community to create a service that EXPOSES YOU!!!!" and all that donkey manure.
- bare onion service, if following Aaron's suggestion of dropping the onion, would lead to BS, which is not really an acronym anyone would want to have. :)
I do like FS, but only if the performance improvements are quantifiably larger. Obviously the whole point of this endeavour is to make the speed and performance better, but until it is measured, I'm concerned "Fast (Onion) Service" may somewhat misrepresent the actual outcome. For example, hitting terribly slow "Fast Services", presumably because the service is so well loved that thousands of people use it, would upset some people not really understanding why it's slow.
With the above comment, that's why I like DS, because regardless of quantifiably increased performance, it is clear that it is a direct connection to the [Service], and there is no implied improvements beyond the statement that it's direct.
Then there's also "Direct Public (Onion) Service", which would be DPS or DPOS...
Matt Speak Freely
Following on Aaron's suggestion, and further pushing my own wee agenda, what about PS? it works because even if someone confused the acronym for something else, it still works. And it matches well with HS/OS.
- Public (Onion) Service
- Peeled (Onion) Service
- Pseudo (Onion) Service <-- I like this as well, for various reasons
I don’t prefer these suggestions because 1. Public Onion Service: “Public” doesn’t describe the desired property well. A hidden service can be public in the sense that it is publicly known an accessible. Similarly, it suggests that other onion services are private, or members-only. 2. Peeled Onion Service: “Peeled” isn’t a very informative descriptor. What is peeled? What does "peeled” mean in this context? 3. Pseudo Onion Service: This makes it sound like the service it’s a fake onion service. But the security properties are very real.
- exposed onion service, in my mind, would lead to people thinking the
connection is in no way secure, because it is "exposed."… this may lead to the wrong understanding by a small but loud group of people.
I can see that, although I would say that we shouldn’t let the fringe choose how we communicate.
- bare onion service, if following Aaron's suggestion of dropping the
onion, would lead to BS, which is not really an acronym anyone would want to have. :)
BOS could work. Conversely, POS means “piece of shit” to me, but PS could work for the above suggestions.
I do like FS, but only if the performance improvements are quantifiably larger. Obviously the whole point of this endeavour is to make the speed and performance better, but until it is measured, I'm concerned "Fast (Onion) Service" may somewhat misrepresent the actual outcome. For example, hitting terribly slow "Fast Services", presumably because the service is so well loved that thousands of people use it, would upset some people not really understanding why it's slow.
I agree with this. Also, there are things that a direct onion service could do to improve security that a hidden service can’t do, such as providing multiple locations as options to the client and providing information about the Internet paths it takes to Tor relays.
With the above comment, that's why I like DS, because regardless of quantifiably increased performance, it is clear that it is a direct connection to the [Service], and there is no implied improvements beyond the statement that it's direct.
And, as Alec Muffett said, it has the advantage of being "attractively mundane”.
Cheers, Aaron
On Mon, Apr 20, 2015 at 08:51:59AM -0400, A. Johnson wrote:
Why not simply "onion service"?
Because we have already started using "onion service" to cover what we previously called "hidden services”
Right.
My latest thinking about the terminology is that we should call them something like "client side onion service" (CSOS, suggested pronunciation C-sauce).
These suggestions are too long, in my opinion, and a short acronym cannot substitute for a short name. Of primary importance, I think, is that the name be easy to use and is meaningful. I like the [modifier]+"onion service” approach, which can be further shortened to [modifier]+”service” when the onion context is clear. This already works for “hidden service”, which we can more clearly refer to using “hidden onion service”. Some options following this pattern are
I agree with the above.
- fast onion service
- exposed onion service
- direct onion service
- peeled onion service
- bare onion service
I don't like any of these. They all fall into the same trap as "hidden service" or another I'll set out momentarily. I was going to mention these issues in my last message, but didn't wanted to focus on a positive suggestion rather than go on too long about why I was rejecting alternatives.
The problem with "fast", "direct", and maybe "bare" is that they describe some property we're trying to provide with these. Like hidden, I think the chance that they will evolve or be applied in some way for which these terms won't apply is too great. Then we'll be saying things like, "When this design was first proposed this was considered a fast(direct) connection vs. what the previous onion services design did. We now have foo, which is faster(more direct), and we're using fast(direct) onion services for application bar which is not actually very fast(direct) and we don't really care if it's particularly fast(direct) for this application" etc. Think about the extent to which hidden services are used for other things than serving up web pages.
The problem with "exposed", "peeled", and maybe "bare" is that these all imply that these are onion services that are diminished in some way. I can just picture the paper titles and, worse, inflamatory news headlines the first time someone shows some attack on some aspect of the design (or more likely on something else entirely on a system that is configured as such a service). I think anything implying vaguely lesser onion services is unacceptable.
This is why I'd like to have a name that reflects exactly and only what the system does, which is require that connections use Tor. Actually the more I ponder this, the more I return to a point I raised weeks (months?) ago that I'd just as soon not call it [modifier] onion service, because if it ends up not having the .onion domain name or requiring lookup in the HSdir system etc. it will be a very confusing misnomer vs. what we are now calling onion services. I thought I had accepted the [modifier] onion service approach, but I'm going back to my former position.
As we've been discussing, long names are problematic, but the shorter ones that may evolve can be even more problematic. We originally called hidden services "location-hidden services" which we tied back to even earlier terminology noting in the original Tor design paper "Rendezvous points are a building block for location-hidden services (also known as responder anonymity)". The shortening to "hidden service" was convenient for discussion, but lead to many of the problems we now face. This is another reason why [modifier] onion service is problematic; it will almost certainly get shortened in use, just as location-hidden service did.
I think the best thing would be a neologism that, most importantly, won't get abused or cause confusion because of some connotation of the name. Bonus if it will nonetheless make sense to anyone who knows the system, and can be explained in a few simple words to anyone who doesn't.
Here's one suggestion: must-tor service (or mustor service if we want to be even more compressed. Either can also play off the idiomatic connotation of only accepting those connections that pass muster, but that's really secondary). If someone knows even a little about Tor (even if they've never heard of onion services or hidden services) they can maybe guess what the service is about. If they know nothing about Tor, saying that connections to this service must come through the Tor network explains the name immediately, even to someone whose next question is "What's the Tor network?".
Note that if mustor services also have .onion addresses I don't see that as a problem at all. I could explain that too, but I'll stop here for now.
aloha, Paul
The problem with "fast", "direct", and maybe "bare" is that they describe some property we're trying to provide with these. Like hidden, I think the chance that they will evolve or be applied in some way for which these terms won't apply is too great.
I disagree in general. Hidden service is still a perfectly accurate term. “Fast” may have this issue if such services change and take advantage of the fact that the server location is known for other purposes (e.g. location-based security improvements).
The problem with "exposed", "peeled", and maybe "bare" is that these all imply that these are onion services that are diminished in some way.
I can see this with “exposed” (although it actually has the advantage of making it clear to the operators that the service is *not hidden*). Neither “peeled” nor “bare” seems negative to me.
because if it ends up not having the .onion domain name or requiring lookup in the HSdir system etc.
This doesn’t seem relevant. We are discussing an existing proposal, in which the .onion domain and Tor's name resolution service are used.
This is another reason why [modifier] onion service is problematic; it will almost certainly get shortened in use, just as location-hidden service did.
The obvious and suggested shortening (i.e. omitting the word “onion”) works well, in my opinion.
Here's one suggestion: must-tor service (or mustor service if we want to be even more compressed.
This reminds me of the “Tor-required service” suggestion you initially made. I dislike like it for the same reasons, the primary one of which is that it uses two entirely separate names for services that actually will probably indistinguishable to the user. That’s why I like the “onion services” umbrella over both hidden and fast/direct/exposed/public/peeled/etc.
Best, Aaron
On Mon, Apr 20, 2015 at 01:05:16PM -0400, A. Johnson wrote:
The problem with "fast", "direct", and maybe "bare" is that they describe some property we're trying to provide with these. Like hidden, I think the chance that they will evolve or be applied in some way for which these terms won't apply is too great.
I disagree in general. Hidden service is still a perfectly accurate term. “Fast” may have this issue if such services change and take advantage of the fact that the server location is known for other purposes (e.g. location-based security improvements).
I disagree. Firewall punching service administration may also involve hiding, which may or may not be viewed as a benefit. But calling this hidden is not a good description of the most salient or important aspects of the service. Similarly for the authenticated services Griffin and I described in "Genuine Onion". Admittedly the latter currently is largely academic with only a few working examples at the moment.
The problem with "exposed", "peeled", and maybe "bare" is that these all imply that these are onion services that are diminished in some way.
I can see this with “exposed” (although it actually has the advantage of making it clear to the operators that the service is *not hidden*). Neither “peeled” nor “bare” seems negative to me.
You haven't seen the headlines in Time Magazine or The Register yet.
because if it ends up not having the .onion domain name or requiring lookup in the HSdir system etc.
This doesn’t seem relevant. We are discussing an existing proposal, in which the .onion domain and Tor's name resolution service are used.
See my last paragraph below.
This is another reason why [modifier] onion service is problematic; it will almost certainly get shortened in use, just as location-hidden service did.
The obvious and suggested shortening (i.e. omitting the word “onion”) works well, in my opinion.
What then was wrong with clientside service, or evn client service? (Although I am again increasingly sour on the idea of trying to treat these and heretofore "hidden" services as somehow broadly the same animal.)
Here's one suggestion: must-tor service (or mustor service if we want to be even more compressed.
This reminds me of the “Tor-required service” suggestion you initially made. I dislike like it for the same reasons, the primary one of which is that it uses two entirely separate names for services that actually will probably indistinguishable to the user. That’s why I like the “onion services” umbrella over both hidden and fast/direct/exposed/public/peeled/etc.
Thank you for making my point. My fundamental concern is that these are two separate services with important differences. We will use the same (or too similar) names for them, and the user will be confused about which s/he is using. (Note that user here includes the Tor user setting up the service, not just the one who is the client of that service. Also those doing subsequent design and analysis are very much steered by terminological choices "anonymity", "hidden", etc.) A similar point was raised to me after my post earlier today by someone in a private response. I encouraged reposting the point in public discussion in this forum, but I haven't heard back or seen that, so will wait to say more.
A primary motivation here on terminology is to make sure we don't rush ahead and assume terminology and/or design that runs them together and therefore decide that the design and/or terminology that follows this running-together naturally follows. That's viciously circular justification.
Best, Aaron
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Apr 20, 2015, at 1:40 PM, Paul Syverson paul.syverson@nrl.navy.mil wrote:
On Mon, Apr 20, 2015 at 01:05:16PM -0400, A. Johnson wrote:
This is another reason why [modifier] onion service is problematic; it will almost certainly get shortened in use, just as location-hidden service did.
The obvious and suggested shortening (i.e. omitting the word “onion”) works well, in my opinion.
What then was wrong with clientside service, or evn client service? (Although I am again increasingly sour on the idea of trying to treat these and heretofore "hidden" services as somehow broadly the same animal.)
Here's one suggestion: must-tor service (or mustor service if we want to be even more compressed.
This reminds me of the “Tor-required service” suggestion you initially made. I dislike like it for the same reasons, the primary one of which is that it uses two entirely separate names for services that actually will probably indistinguishable to the user. That’s why I like the “onion services” umbrella over both hidden and fast/direct/exposed/public/peeled/etc.
Thank you for making my point. My fundamental concern is that these are two separate services with important differences. We will use the same (or too similar) names for them, and the user will be confused about which s/he is using. (Note that user here includes the Tor user setting up the service, not just the one who is the client of that service. Also those doing subsequent design and analysis are very much steered by terminological choices "anonymity", "hidden", etc.)
I think new users might not appreciate the difference between similarly named terms and then choose the wrong one to their detriment. It seems better that they should later learn of shared technology that's not clear from the naming differences than be surprised by differences in security properties that they incorrectly assume from similar names. (Perhaps more generally, the naming should reflect how users---broadly construed---should think about these things rather than the mental models that are useful as developers.)
Best, adj
I think new users might not appreciate the difference between similarly named terms and then choose the wrong one to their detriment. It seems better that they should later learn of shared technology that's not clear from the naming differences than be surprised by differences in security properties that they incorrectly assume from similar names. (Perhaps more generally, the naming should reflect how users---broadly construed---should think about these things rather than the mental models that are useful as developers.)
It is actually for usability that I dislike making unnecessary distinctions. “Onion service” makes it simple to clients: xyz.onion = service accessible only through Tor.
And the problem for servers doesn’t seem so bad. Setup process: User: I’d like to set up an onion service. System: Would you like a hidden/protected/obfuscated onion service or a direct/exposed/peeled/flagrant service? Choose a direct service only if you want to expose the server location in order to improve performance [and security] for your clients. (Default: hidden service) User: I don’t like reading, I’ll just go with the default.
The point is that these security/performance choices should not be exposed to the clients, but they can be safely exposed to server operators.
Aaron
On Mon, Apr 20, 2015 at 03:18:06PM -0400, A. Johnson wrote:
I think new users might not appreciate the difference between similarly named terms and then choose the wrong one to their detriment. It seems better that they should later learn of shared technology that's not clear from the naming differences than be surprised by differences in security properties that they incorrectly assume from similar names. (Perhaps more generally, the naming should reflect how users---broadly construed---should think about these things rather than the mental models that are useful as developers.)
It is actually for usability that I dislike making unnecessary distinctions. “Onion service” makes it simple to clients: xyz.onion = service accessible only through Tor.
This may be the central source of our disagreement and underscores the importance of terminology. I think of "onion service" as meaning a service that is reachable only inside of Tor not merely accessible only through Tor.
Suppose someone has a sensitive file that they don't want the wrong people to obtain or obtain before, e.g., an intended public release. It would be good for them to easily tell whether the server they're trusting with that file is location protected or self-authenticated or.... If both Tor-required and heretofore hidden services terms are called onion services, then it won't be apparent simply from the address. (Substitute whatever terms you like for "Tor-required" and "heretofore hidden", which I'm hoping are adequately denoted by my usage here.) And, do we require self-authentication a la current hidden services for those that we want to be faster and more convenient if it e.g. would significantly affect performance? My point is that if we assume these are all called 'onion services' we are likely to assume in all kinds of design requirements or trade-offs without first deciding what we want these things to do and whether it thus makes sense to bind them together in this way (or not). This will then be baked into what 'onion' will mean and entitle one to assume, even or especially for the users that cannot articulate this technically. (As an imperfect analogy, think of the semantics of the lock icon or the green highlighting etc. in URL bars.) Put differently, whoever's terminological preferences win, we should get much clearer on these things before we treat this draft as more than a toy to help us work these out.
aloha, Paul
FYI, I have been collecting the proposed names at https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Terminology. I also just added two suggestions that haven’t been on this thread: “flagrant onion service” and “open onion service”. Thanks for Alec Muffett for the former. Apologies if I missed your suggestion - please feel free to add it!
This may be the central source of our disagreement and underscores the importance of terminology. I think of "onion service" as meaning a service that is reachable only inside of Tor not merely accessible only through Tor.
I have never though of “onion service” as applying only to hidden services, starting with my initial terminology tor-dev post in February [0]. Also, the semantics of “inside” and “outside” Tor isn’t so clear to me, because hidden services seem pretty “inside” Tor to me in the ways that matter (viz. onion-encrypted, running Tor software).
Suppose someone has a sensitive file that they don't want the wrong people to obtain or obtain before, e.g., an intended public release. It would be good for them to easily tell whether the server they're trusting with that file is location protected or self-authenticated or….
I don’t think that the user should rely on the type of onion service to verify server anonymity. Instead they should have some exogenous trust in the server operator, because there are so many ways to leak server location/identity outside of its Tor configuration.
Best, Aaron
[0] https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I like the term "onion service" to refer to a service that requires the use of Tor to access.
For onion services whose operators do not want their identities discovered, I suggest renaming "hidden service" to "anonymous onion service".
For onion services that do not need anonymity (location is known but Tor must be used to access), I think "known onion service" is a great name ("identified onion service" also make sense, but I prefer "known" to "identified").
These suggestions are added to the wiki page: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR/Term inology
Cheers, Rob
Whether it's public/fast/direct or hidden, they are both Must-Tor services. You can't get away from that basic requirement.
Tor Services, being either Fast/Direct/Public or Hidden/Onion, could be the generic term for either. It would get away from any possibility of what OS is - Onion Service vs. Operating System. MustTor could be a term to reflect a requirement to access the Service, but if that's the case you can drop "Must" as that would be a known given, Tor *must* be used. But having MustTor/Mustor as the [open] service name would only provide unreasonable ambiguity to the hidden onion services.
Just to throw a wrench into the mix...
- (OS) Obfuscated Service to replace Hidden (Onion) Service - (DS) Direct Service to represent the new type of Onion Service - (TS) Any [Must-]Tor Service
Those... seem to me to be clear and to the point...
Matt Speak Freely
-
A. Johnson -
Aaron D. Jaggard -
Alec Muffett -
David Goulet -
George Kadianakis -
Jacob H. Haven -
malte＠wk3.org -
Moritz Bartl -
Paul Syverson -
Rob Jansen -
Speak Freely -
Tom Ritter