<div dir="ltr"><div><span style="font-size:12.8000001907349px">I posted this on the IETF lists, folk here might be interested in this work</span></div><span style="font-size:12.8000001907349px"><div><span style="font-size:12.8000001907349px"><br></span></div>Draft at:</span><br style="font-size:12.8000001907349px"><div style="font-size:12.8000001907349px"><a href="https://tools.ietf.org/html/draft-hallambaker-cryptomesh-00" target="_blank">https://tools.ietf.org/html/draft-hallambaker-cryptomesh-00</a><br></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">After working on the problem of securing end-to-end email for quite some time. I now have a scheme that really does meet my design goal of being just as easy to use as regular mail.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">If you are on a Windows box using Windows LiveMail (nee Outlook Express) and you run the mesh profile manager it will automatically create and register your S/MIME keys in the Mesh, apply for certificates and configure your client to use them. The only thing the user has to do is to select which accounts to enable for use with 'endymail' - end to end encrypted email. Once the keys are registered, use is totally automatic.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">If you then want to enable endymail on a second machine, all you have to do is to go to that machine, run the profile manager, give it your account name, request that it enable that machine, then go back to your first machine (or another machine you have approved for admin access) and approve the request. Job done.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Behind the scenes, the necessary private keys are being encrypted and shared through the mesh. Unlike systems such as LastPass, the mesh is not a trusted service, the keys used to exchange the configuration for endymail in the public PKI (e.g. CA based, OpenPGP, something new) are managed using a personal PKI.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">There is some cleanup work to be done. The code does not support OpenPGP yet but that is just a matter of some code. Getting the code so it will work outside my lab is taking some time. </div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Before working on that, there is another, much more important problem to solve - deployment. And to do that I need to think about deployment engineering as a separate problem. The value of a scheme in which anyone can send endymail is in the $billions ($1 per email recipient times 3 billion users ~= 300 billion). The current value my system adds to email is $0 ($1 per email user times 0 recipients times 1 user).</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">And S/MIME and OpenPGP face the same problem. They have never achieved critical mass and so all the potential of 'network effects' and 'viral marketing' become the 'chicken and egg' problem.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">So here is how I propose to address deployment. Endymail isn't very valuable to the individual user until widely deployed. So instead provide a system that addresses their biggest pain point - remembering the usernames at all the 100s of Web sites they use that require username&passwords. Remembering passwords is easy because you just use the same one everywhere. Unless they have a password manager, that is.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Systems like LastPass have appeared to meet a real user need. But they don't use end to end security and they aren't built on open, widely reviewed standards. So the user is putting themselves in the hands of a third party who demands way too much trust.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">The mesh is designed be an untrusted service that can support secure exchange of any sort of data through end to end encryption. It is sort of like NNTP for cryptographic keys. To prevent abuse there will have to be admission control or else we will have idiots trying to stream 4k video over it. Denial of Service by people trying to wreck the mesh is a bigger problem, any system that claims it can't be breached will have people trying to attack it regardless of the fact that the breach claim only covers confidentiality and integrity, not service.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">In the short term that will probably mean requiring some form of proof of work scheme so that the cost of an attack to an attacker is less than the value. But once we get the email scheme built out, an introductions model could offer the same degree of protection without the overhead.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Right now I am reworking the code and specs to make the scheme as application neutral as possible and to stand up a test mesh.</div></div>