[liberationtech] How to make the Internet secure

[carlo von lynX]

Coming from: Phillip Hallam-Baker <phill at hallambaker.com>
> One of the big problems I have found in trying to argue for ways we can
> improve Internet security is that there are two camps. The incrementalists
> will only look at solutions that provide an improvement on the status qujo
> in one area and the perfectionists insist that any solution that does not
> solve every possible problem isn't worth considering.

Oh! Finally the clean-slate camp is acknowledged. Back when we
participated at STRINT[1] there were only 3 of us proposing a
clean-slate approach, and we were acknowledged in the final
report with one or two lines of text.

> How about we do both?

Yes, indeed. But, please, don't call us perfectionists. Our only
difference from the incrementalists is the awareness that the
number of deficiencies in the current TCP/IP stack is so epic[2],
it is A LOT LESS WORK to start with a new approach. From then on
there is still plenty to be done and a lot to increment and
improve, and we don't want to wait until we achieve perfection.

Considering that there are already several implementations[3]
going in that direction and there is even a law proposal[4]
that depends on a clean slate approach in order to be *able* to
guarantee basic civil rights by technological means, not by the
good will of the authorities. Making the web respect 
constitutional by design is possible.[5]

[1] https://www.w3.org/2014/strint/papers/65.pdf
[2] http://secushare.org/broken-internet
[3] http://youbroketheinternet.org/map
[4] http://youbroketheinternet.org/#legislation
[5] http://www.w3.org/2014/privacyws/pp/Carlo.pdf

> Also to save time:
> 
> [...]
> 
> * Yes, I need help, a lot of help

Have a look at gnunet.org. The description you make (that I 
replaced with [...]) sounds like things that are already possible.
gnunet started in 2003, so it may be slightly ahead of you...

> OK so how is this possible?
> 
> First observation is that we now have several protocols that provide users
> with end to end security that are really easy to use. The only real problem
> I have with those systems is that they operate inside walled gardens. They
> are not going to be a replacement for email.

Doing a replacement for email means doing a replacement for Facebook.
Many people are avoiding to ever start using mail, since they can do
it all on Facebook and the cumbersome aspects of mail are resolved
(instead of having to deal with user at host addresses they just click
on people). That's why secushare is working on distributed social 
networking over GNUnet which as a side effect brings about the kind
of mail system we all should be using: Easier than Facebook, but
absolutely privacy-preserving. And we're not the only project heading
in that direction. There's also Patchwork, Briar...

Still other people like the idea of maintaining compatibility with
existing SMTP infrastructure. There are several ways to go about
that. pEp is pursuing one of them.

> There are three contributions made by the Mathematical Mesh:
> 
> 1) An infrastructure for managing and using client keypairs.
> 
> Adding cryptography to a protocol is actually quite easy when both parties
> have public keypairs. So if we have an infrastructure that allows a user to
> 'glue' all their devices together into a personal mesh such that they all
> have keypairs provisioned for each cryptographic purpose they might need
> them for, cryptography becomes really easy for the user.

That is accurate.

> 2) Extend a direct trust model into the DNS
> 
> We all know about TOR and onion routing. Well what if I could have an email
> address that included my OpenPGP fingerprint? Well we can. Just use the
> xx-- DNS label prefix to mark the fingerprint as not an ICANN DNS labnel
> and we can make the fingerprint the TLD:
> 
> alice at example.com.mm--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE
>
> [...]

This sounds like an incremental approach to me. Why not simply do the
routing by public key? Why not map the nickname or realname of a person
to their public key using a mechanism like GNS? A lot less cumbersome...

> 3) Use of Proxy Re-Encryption (Recryption)
>
> [...]

Not sure if what you describe is similar to the pubsub mechanism we
added to gnunet which is able to distribute (multicast TBD) website
content to all short-term and long-term subscribers. This way, there
never really is a traditional web server - the web is a continous
stream, or a set of files kept forever in a distributed mesh of nodes.
See [5] for details.

> Using recryption allows us to develop protocols in which Alice is able to
> publish a single encryption key but read her email on three different
> devices, each of which has a separate decryption key so that she can
> mitigate the risk if one of the devices is lost.

Interesting, so far we are working on automation of master keys.

> Once we have that infrastructure, all else becomes straightforward. My
> original goal with the Mesh was to make it easy to configure S/MIME and
> OpenPGP. David Clark asked me to add SSH which I immediately realized could
> be the killer app because the big problem with configuring SSH is that if
> you do it to a machine at a remote site, 1000 miles away and you screw up,
> someone has to get on a plane to fix it.

With gnunet, a non-censorable, non-dossable, non-deterministic route
is established to the remote node. Once that is done, you can log in by
rsh or telnet. No need to use further crypto. It's the same also with
cjdns, Netsukuku and a few other similar tools, but those aren't as
resistant to attacks. So I don't really see how SSH can be a killer
app again.

> I am looking for help to make this happen.

Yes, but it would be good to first find out if there is something in 
your design that is missing from ours, or if we are a decade ahead.

///

Btw, expect a new release from gnunet and a secushare prototype soonish.
Re-inventing the Internet takes a lot of time, but that doesn't mean
we're not getting there.


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