[liberationtech] How to make the Internet secure

[Phillip Hallam-Baker]

On Wed, Feb 1, 2017 at 2:15 PM, carlo von lynX <lynX at time.to.get.psyced.org>
wrote:

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

​The original email was sent to IETF.​

​IETF is currently working on a replacement for TCP called QUIC which runs
over UDP. This provides for multiple streams. There is also momentum behind
the JSON encoding approach.

My point is that I am not opposed to redesigning the application layer from
scratch. But I am not going to insist on it either. I am not offering an
either/or of incremental or start from scratch. I am saying that I can fix
the security problems in SMTP with S/MIME or OpenPGP in a framework that
then allows an easy transition to Next Gen Mail.




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


​Again, that was simply for IETF consumption. Without the recitation of
goodness, the discussion inevitably gets dragged into the weeds by someone
insisting that I have not thought of X. When chances are I have thought of
X a great deal.​



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

​I believe that mail, chat, voice, video, blog comments and mailing lists
are all separate messaging modalities that need to be addressed in any
replacement scheme. However, there is no reason why it should not be
possible ​to support all of these modalities in a single message format.

​Facebook is not just a messaging infrastructure. It is also an
infrastructure that allows social networks to be defined, published and
applied. The main objection I have to FB is that it is walled garden.

Establishing a uniform identifier that has unambiguous meaning across
domains is the key to breaking up walled gardens.


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


​The reason for not using public keys is security. I want identifiers to be
stable for long lengths of time, potentially a lifetime. It should be
possible to rotate public keys on a weekly basis without cost to the user.

UDF fingerprints can be taken of any data object. They are used in the Mesh
to provide a unique identifier for the signature key of a master profile
that represents a user's personal root of trust.​ The intention is to
permit these to be offline keys that do not need to be used very often and
may well be secured by multi-party key splitting.

​The point of using fingerprints is to provide a baseline which needs no
further validation or external trust sources that can be referenced by the
infrastructures that build on top of it. Use of nicknames, etc is a very
good idea. But just as the Internet protocols are ultimately built on IP as
the basic unit of interchange for packets, there needs to be a basic unit
for trust.
​

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


​No.​ I am using a completely different approach using a form of
cryptography developed by Matt Blaze in the 1990s that allows end to end
encryption when using traditional client-server architectures.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20170201/aea59b68/attachment.html>