Re: [tor-dev] Onioncat and Prop224

[George Kadianakis <desnacked@xxxxxxxxxx>]

str4d <str4d@xxxxxxxxxxx> writes:

> [ text/plain ]
> On 27/04/16 22:31, grarpamp wrote:
>> On 4/25/16, Tim Wilson-Brown - teor <teor2345@xxxxxxxxx> wrote:
>>>
>>>> On 22 Apr 2016, at 17:03, grarpamp <grarpamp@xxxxxxxxx> wrote:
>>>>
>>>> FYI: The onioncat folks are interested in collaborating
>>>> with tor folks regarding prop224.
>>>>
>>>> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt
>>>
>>> I'm interested in what kind of collaboration onioncat would like to do on
>>> prop224, next-generation hidden services.
>>> It would be great to work this out in the next few weeks, as we're coding
>>> parts of the proposal right now.
>> 
>> Yep :) And I know Bernhard was hoping to get in touch with Roger
>> on this before long.
>> 
>> Basically, prop224 HS being wider than 80 bits will break onioncat's
>> current HS onion <---> IPv6 addressing mechanism.
>> 
>> They're looking at various backward compatibility options, as well
>> as possibly making side use of the HSDir DHT, or even integrating
>> more directly with the tor client.
>> 
>
> Just FYI, I recently migrated all of I2P's spec proposals to the
> website, and came across a seven-year-old proposal that Bernhard wrote
> about improving I2P support in GarliCat:
>
> https://geti2p.net/spec/proposals/105-garlicat-name-translation
>
> I don't know how well it has aged, but given that Tor is now facing the
> same issues that I2P has, perhaps it can be of some use if resurrected
> from the dead :)
>

Hello,

disclaimer: I've never used onioncat and I'm not even sure what are the use
cases for it. I just read the docs on its webpage in an attempt to understand
the system and maybe contribute to this thread. I probably don't understand the
system sufficiently yet.

Starting with a question wrt the "Scalable Solution" for I2P, I did not exactly
understand how the DNS approach would work for garlicat.  Would GC do the DNS
request? Or the application? And to which DNS server? Some GC-specific DNS
server?  The solution seems plausible, but it requires the extra DNS protocol
round trip.

BTW, if the application-layer protocol supports DNS, can't we just fake the DNS
protocol part and resolve the DNS query inside onioncat? So, Alice is in
onioncat as "aliceonioncathiddenservice.onion" and she passes her onion to Bob
who wants to torrent with her through onioncat. Alice gives
"aliceonioncathiddenservice.onion" to her friend Bbo, and Bob tries to connect
to it through his application (e.g. a torrent client). Bob's application will
probably do a DNS query for the onion address, which onioncat can intercept (?).
At that point, onioncat can register the onion address as the destination,
and pass back a fake IPv6 address to the torrent client. From that point and
on, the torrent client will use the fake IPv6 address, and onioncat will
reroute the connection through the onion circuit to
"aliceonioncathiddenservice.onion".

I'm not sure if the above idea will work, but even if it does, it's worse than
the current onioncat, since it requires the application-layer protocol to
support DNS.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev