[tor-dev] Proposal: Rendezvous Single Onion Services

[Tim Wilson-Brown - teor]

> On 12 Feb 2016, at 15:57, Roger Dingledine <arma at 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.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160212/77cfaec7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160212/77cfaec7/attachment-0001.sig>