[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Martin Schanzenbach
Subject: Re: [GNUnet-developers] Reverse resolution of VPN/GNS
Date: Fri, 04 Nov 2016 18:46:36 +0100


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

First you say:
On Fri, 2016-11-04 at 17:58 +0100, carlo von lynX wrote:
> This summer I reported
> > 
> > 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:
> 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.


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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]