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

[carlo von lynX]

Hello Martin, long time no see.
Sorry if this sounded like a rant, I'm just surprised that
after six years gnunet and secushare still don't know each
other as well as they should...

On Fri, Nov 04, 2016 at 06:46:36PM +0100, Martin Schanzenbach wrote:
> Yes, this is what reverse resolution is for. The only thing you can
> know about the "caller" is his peerid/identity, at best. 

Yes, I've fumbled around with gnunet-cadet and was about to
implement a solution by working directly with the CADET
API, but I see huge potential in adapting tons of existing
software if it just works out via DNS emulation.

> Now, the question is how you find a path from _your_ identities to that
> peer. The other way around not necessarily useful.

You mean a resolution path. Well, that is the ivory tower
in the room: we don't *need* to resolve any damn random
public key. We just need to recognize those we are in a
social relationship with, so we already have the information
in our local graph. Strangers remain anonymous until proven
otherwise (in the case of a person contacting a company
for example) and if I set up a public FTP daemon for my
friends it is NOT supposed to work for random strangers.

If somebody needs to get friends with me, then the content
of the transmission will have the necessary cryptographic
auth data - so we first complete the rendez-vous process,
then that person is given a .gnu and thus VPN starts working.
Therefore, even for an early prototype, we don't need to
resolve strangers or 2nd degree friends.

Later, when the secushare social graph is fully functional,
we will *know* all the public keys of our 2nd degree (and
possibly beyond, depending on each person's privacy settings)
friends so there is no need to look any of them up via GNS.

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

Are you telling me the local ego has no way to enumerate
their own GNS zone to find that person's pubkey?

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

Reverse resolution by design is public, that's why we don't do this.
If a web service is meant to be anonymous, it stays so. If the person
is supposed to authenticate, then they can initiate a social contact
exchange with a proper suitable protocol (we use PSYC for that). To
prevent DoS, SPAMming, phishing and all that *we don't accept* stuff
from strangers, then try to find out if they were meant to be friends.
Either we already know, or they do a proper introduction. It's like
ringing the door bell before coming into my kitchen.

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

The callee either intentionally offers services to strangers - then it
doesn't need any resolution - or it offers services to those people
it already knows. Everything else is dealt with a proper rendez.vous 
procedure. And yes, it has everything to do with social networking,
because doing antisocial gnunet is pointless. We already have
blockchain for that.

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

Yes, just the first degree.

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

In secushare I have pubsubs of all my social contacts. Each pubsub
has a psycstore database. Depending on how much they like me and
into which social groups they add me, I receive pubkeys of people
they are connected to that I should be able to reach out to. See
last month's secushare video for details on this (in German). So
I already have my gnunet/secushare social graph in the psycstore
database and just need to SELECT over it. No need to consult any
DHT, let alone have it be public.

More on this in...
        http://secushare.cheettyiapsyciew.onion/rendezvous
        http://secushare.cheettyiapsyciew.onion/identity
        http://secushare.cheettyiapsyciew.onion/security
        http://about.psyc.eu/social_graph

-- 
  E-mail is public! Talk to me in private using encryption:
         http://loupsycedyglgamf.onion/LynX/
          irc://loupsycedyglgamf.onion:67/lynX
         https://psyced.org:34443/LynX/