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

[carlo von lynX]

[OT] First of all, sorry if anything I write ends up sounding
unlike the easy peacy chilled out way it sounds when I write it up.
I have a bad habit of pushing people verbally, put it is always
meant in a constructive motivating way... which I know can easily
backfire.. it's a problem of the Internet whose only solution
I know is.. again.. social.. from the sociological studies I
involunteraly undertook in the last years, the only known solutions
to escalating undertones in digital communication is.. moderation.
I didn't find a single research suggesting otherwise. So to take
the unintended heat out of discussions the best way is to have a
third party moderator that recognizes the escalation of which the
participants frequently aren't aware. This is not an opinion, this
is the current state of knowledge in sociology. I documented all
of this in http://my.pages.de/convivenza - it has seen contribution
from several people, mostly Italian pirates. And it got accepted as
an official document of the group, which is a big step to take for
a bunch of netheads: accepting that the science of sociology comes
to completely diverging knowledge than what the Internet ideology,
typically fueled by documents like the Declaration of Independence
of Cyberspace, proposes. That document is well-intended, but does
not work sociologically. Enough off-topic. [/OT]

On 11/05/2016 07:12 PM, Martin Schanzenbach wrote:
> I did read secushare pages btw. I even watched the latest Datenspur

Thank you very much and very sorry that I assumed you didn't.
I thought after digesting that material it would become logical
and self-evident that we shouldn't stick to insecure non-social
methods, but apparently that is not the case.

> Now if you read your mails again and don't see the hubris in them I
> cannot help you.

One things is having an opinion, another is trying to communicate a
lot of previously elaborated thinking - and failing at finding a
way to reduce it to a few paragraphs. Both can look like hubris, I
guess.

Christian, thanking for summarizing our discussion so far. 

On Sat, Nov 05, 2016 at 07:43:32PM +0100, Christian Grothoff wrote:
> At a higher level, my view is that we should really avoid this silver
> bullet idea (which for Carlo is SecuShare's design): GNUnet is about
> providing a broad toolchest of (quality) solutions to common problems
> when building secure (decentralised) network applications.  In this

I would argue to not entirely drop the silver bullet idea, but rather
try it out first before investing energy in solutions to problems we
don't know we have and prone to privacy issues. I asked for use cases
that would suggest not to try out the silver bullet approach first
and you are bringing up a corporate scenario. That's cool. Let's look
into that:

> Martin is looking at solutions that in my view relate to more corporate
> use cases with access control, credential management, etc.  This is a
> very different application domain, but the Internet has many

Are you talking of internal applications of companies? Like robots and
automations communicating in an IoT manner within a company? Most
likely company will simply do a centralized system, maybe upgrading to
internal TLS connections using a homemade X.509 certificate authority.
But should they for any reason want to run their internal systems over
GNUnet, then the easiest way to manage access control between the
devices would be to create an authority hierarchy based on public keys.
That can be done with several of our tools in the toolchest. In any
case I cannot think of a situation in which there is no easy way to
look-up the credentials of the incoming CADET, requiring to figure out
a world-public GNS-based way to do it.

> applications and let's not forget that corporations are people too. Eh,
> scratch that, I mean that our corporate masters also use the Internet

That's a point I think we will always head to: realizing that business
use cases are still about humans interacting, and the best way to
keep your systems secure is to only let those communicate with each
other that fulfilled a proper get-to-know-each-other procedure.

Instead of having to guarantee the IT security of entire stacks of
foreign software like PHP apps, device drivers, firmwares, quickly
hacked up python scripts to do some service... we simply ensure that
everything before the get-to-know-each-other procedure, essentially
CADET and a few other GNUnet modules, is as free of vulnerabilities
as we can provide - thus reducing the attack surface for a truly
criminal attacker dramatically.

If we agree that such a move is a huge step into the future for the
whole of IT security, then doesn't it start making sense that a
reverse look-up of random attackers isn't a feature we really need?

> and we shall serve them. At least for the occasions where they may have
> seemingly legitimate needs.

Then let's look at the "public" corporate scenario: purveying a
"website" to potentially billions of humanoids. We could go down
the path of Tor, making hidden services over gnunet-vpn. I see
several disadvantages in that:

- Making such an architecture scalable involves finding a way to
  somehow load-balance users to a large set of gnunet "servers".
- It may involve sharing the company private keys among a cloud
  of gnunet nodes.
- As we can experience when running a public ".onion" service on
  Tor, when using traditional protocols on top, all kinds of DoS
  and break-in attempts will be made on the exposed service.
- It perpetuates the web's sickness of creating artificial
  urgency, as discussed on http://secushare.org/anonymity.
  This raises risks of de-anonymization.
- Anonymity is also threatened by maintaining all the surveillance
  properties of HTTP, HTML, Javascript etc.

This summer CADET was enhanced to use shared secret strings
instead of traditional port numbers when addressing subsystems
over GNUnet. This should have happened in a more premeditated
fashion since real-life use of gnunet-vpn still seems to be
affected, but conceptually that was a move in the absolutely
right direction. Running a service is not by itself a threat as
it currently is in Tor - only if you hand out the shared secret
to the general public, which is what a company would have to do
to offer a traditional web server over gnunet-vpn.

What IMHO we should do instead is described in
http://secushare.cheeettyiapsyciew.onion/business

We structure websites into as many pubsubs as needed, provide
a way to map hyperlinks to the respective pubsubs and hand out
the content by having users subscribe to them. This changes the
rules for the web as follows:

- Any website is scalable because a multicast tree is formed.
  No more inequality between corporate and private websites.
- No website can remote control a web browser to phone home or
  do surveillance things using Javascript. The website exists
  as a bunch of files on the hard disk or FUSE view of the
  psycstore db or a microhttpd view of psycstore (no need to
  decide yet) and the browser is disallowed to do HTTP into
  the wild west web from there.
- Anonymity properties are fantastic since you can subscribe a
  popular website from anyone that already has it. The company
  can only measure its popularity using traditional surveys,
  just like they do for TV.
- There is essentially no way for websites to be hacked or
  defaced as long as the gnunet/secushare pubsub subsystem
  isn't vulnerable. No vulnerabilities of systems at the corps
  like PHP etc are exposed.
- Server-side dynamic websites need to be redone using proper
  protocols that can be checked for human rights compliance.
  PSYC is a suitable format for that.

So, how does a company get in touch with a customer? They push
an update down the pubsub, trusting that the customer will
look into it if they care. No company has a right to spam its
customers, but customers can express voluntary interest by
subscribing to the pubsubs.

And how does a customer get in touch with a company? They run
a suitable communication protocol like the ones we are
developing, ensuring that a new pseudonym ego is used by
default and authentication for business transactions is only
granted when anonymous TALER payment is not good enough.
If necessary, a personal social introduction can be made
using the get-to-know protocol. We have many options how to
work out the details from this point on.

> So what we can debate (without accusations please) is whether
> Martin-style "global" reverse lookups is socially/technically useful for
> SecuShare.  Maybe Carlo is right and it is not. However, GNS is more

No, I don't think we need to discuss whether secushare would
use that. I want to discuss whether we should just focus on
getting the pubsubs working so we can implement a first prototype
of the silver bullet and *experience* whether any of the use
cases would need "reverse lookups". My mental extrapolation of the 
future suggests that doing tools with an old Internet type of 
mindset will make people use GNUnet in the old way, perpetuating 
bad habits of surveillance and insecurity. We already have Tor and 
I2P for that.  What about focusing and getting these pubsubs to 
work, and once we have pubsub-based websites (which is pretty easy
to do.. with a bit of glue between gnunet-social and microhttpd)
maybe the wish for less safer solutions disappears. With such a
powerful tool entering the gnunet toolset, a lot of problems might
start to totally make sense to solve in a simpler and more privacy-
preserving way - not just corporate ones.


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