On 12 Feb 2016, at 15:57, Roger Dingledine arma@mit.edu wrote:
I made some hopefully uncontroversial changes to the proposal in git, but here are the comments that you might want to think about or disagree with before acting on. :)
On Fri, Oct 23, 2015 at 01:54:50AM +1100, Tim Wilson-Brown - teor wrote:
Rendezvous single onion services have a few benefits over single onion services:
* A rendezvous single onion service can load-balance over multiple rendezvous backends (see proposal #255) * A rendezvous single onion service doesn't need an accessible ORPort (it works behind a NAT, and in server enclaves that only allow outward connections)* A rendezvous single onion service can use the existing onion service authorisation mechanisms
Yes, true.
* A rendezvous single onion service is compatible with existing tor clients, hidden service directories, introduction points, and rendezvous points[...] 5. Publishing a rendezvous single onion service
To act as a rendezvous single onion service, a tor instance (or cooperating group of tor instances) must:
* Publish onion descriptors in the same manner as any onion service, using three-hop circuits. This avoids service blocking by IP address, proposal #224 (next-generation hidden services) avoids blocking by onion address.Is this last part true? I think it isn't? If you know the onion address, you can look at a 224-style descriptor and check if it corresponds to that onion address.
You're right, it's not true. We hide the onion address only from those who *don't* know it.
5.1.3 Recommended Additional Options: Performance
LongLivedPorts The default LongLivedPorts setting creates additional, unnecessary connections. This specifies no long-lived ports (the empty list).Why specify this part? Is there much harm in leaving Tor to make a few circuits here and there?
We decided not to implement this in Tor. Operators running hundreds of RSOS instances may wish to add this to the config to avoid building extra circuits.
- Considerations
Is it worthwhile to add a security note about the new surface area we're giving the client, by letting it ask the RSOS to extend to arbitrary destinations? I am thinking #17788.
Yes, we only discovered this issue after the proposal was written, and we've been working through the implications since then.
More generally, I wonder if the denial-of-service and similar "you can make it open new connections" risk is symmetric to the proposal 252 design (that is, you get the same dangers whether it's an external connection coming in to the HS, or the HS making a connection out), or if there's some meaningful difference. For example, I was thinking about sending an intro request that specifies a particular relay, but with a different identity fingerprint in the intro cell, thus forcing the HS to establish a growing number of non-canonical OR conns. I think that particular attack wouldn't work, but I wonder if there are others that would.
We need to think about this a bit more.
- Further Work
Further proposals or research could attempt to mitigate the anonymity-set splitting described in section 8. Here are some initial ideas.
I suggest splitting this whole section 9 into a separate proposal. It seems to be about making it harder to distinguish whether a Tor connection you're observing is being used for an onion service or a normal (exit) connection -- for example, to stymie attacks like the "Circuit Fingerprinting Attacks" from the Usenix Security '15 paper. I think that is a totally different topic than RSOS.
Yes, I think it's a set of ideas that are somewhat orthogonal.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F