Re: [GNUnet-developers] Reverse resolution of VPN/GNS

[Martin Schanzenbach]

Hi,

Thanks for the input. I think you need to elaborate more on this for me
though.

First you say:
On Fri, 2016-11-04 at 17:58 +0100, carlo von lynX wrote:
> This summer I reported https://gnunet.org/bugs/view.php?id=4625
> 
> > 
> > For many kinds of applications we need to authenticate incoming
> > connections as coming from a certain person or at least from a
> > certain peer. The exit daemon is currently not providing a way to
> > find out who is calling. Resolving the virtual IP number would be
> > the most backward compatible method. Best if it resolves to the
> > same "hostname" as the matching outgoing <nickname>.gnu, or even
> > uses the same virtual IP as an outgoing VPN tunnel would use.
> 
Yes, this is what reverse resolution is for. The only thing you can
know about the "caller" is his peerid/identity, at best. 
Now, the question is how you find a path from _your_ identities to that
peer. The other way around not necessarily useful.


> Apparently this has sparked an exciting philosophical debate on
> social graph reverse resolution: https://gnunet.org/gns-reverse-ideas
> 
> I would please ask you to come down from your ivory towers for the
> following reasons:
> 
> 1. Such a reverse resolution method *would* be a local operation
>    if gnunet-social and gnunet-psycstore were actually functional
>    and all the appropriate subscriptions in place.
>    In other words: You are re-inventing secushare.
> 
So you fixed the issue in the bug in theory? Can you elaborate how? I
don't understand...

> 2. In that blog post you are discussing a "public" social graph
>    like PGP's. That is a not exactly futuristic idea and very
>    much inferior privacy-wise to the private social graph planned
>    by secushare.
Well, reverse resolution by design is public. This is particularly
useful for trust establishment scenarios. I.e. I have a webservice and
identity X just logged-in -> reverse resolution to determine if I have
a trust relationship to this person. I don't really care about _his_
trust relationship to me here.

> 
> 3. To make GNS work with existing applications I simply asked to
>    teach gnunet-exit to return the same names that were used by
>    gnunet-vpn to build those tunnels in the first place. The rest
>    of the challenge is then dealt by secushare's pubsub structures.
> 
This does not make sense or you need to explain it to me better. What
use would it be to tell exit how the tunnel was built? Such
(trust)paths (btw I do not agree here that the peers along the tunnel
are in any way related to a social graph or GNS...) are usually not
symmetric or bi-directional. There is no guarantee that this trust path
is actually useful to the callee.

> So all we need to move forward is:
> 
> 1. The closing of that feature request by implementing just the
>    resolution of *known* addresses, in a simple and fast way.
Define "known". A direct trust path? This is also included in the
proposal btw.


> 2. Fixing the bugs in gnunet-social or anything below so that we
>    can avoid having to use older software just because it works.
> 
I have only read the thesis on social to be honest. But by that
knowledge it do not see how it can solve the reverse resolution issue.

BR
Martin

> Thanks a lot for the recent fixes in CADET, Bart. Haven't tried 
> out if they magically get everything working again, yet, but I am 
> hopeful. Who knows, maybe gnunet-social starts working.
> 
>

signature.asc
Description: This is a digitally signed message part