On Wed, Feb 1, 2017 at 2:15 PM, carlo von lynX <l...@time.to.get.psyced.org> wrote:
> Coming from: Phillip Hallam-Baker <ph...@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@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: > > > > al...@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.
-- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu.
