<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">First thing is that its not a plan for deployment of end-to-end secure email, it is a deployment plan for an infrastructure that addresses a different set of security concerns that are much higher priority which just happens to have an end to end secure email capability along for the ride.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This is how email killed the fax machine. People did in fact sit down and try to work out how to do Internet fax and they all failed. What killed the fax was that everyone used email and Nathaniel Bornstein et. al. had added MIME attachments which allowed email to do everything a fax did.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My technology is designed with ease of use as the first priority. I ask 'how much security can I get for the amount of user effort I can expect', not 'how do I defend against every possible attack people can imagine'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So my starting point is a set of three problems which affect small but dedicated communities.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Data at rest</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Email transport was not a major source of breaches even before STARTTLS was deployed. It was the data at rest on the email servers that allowed Russia to roll the DNC. But even in that attack, the bulk of the damage was caused by the Russians capturing the PowerPoint, Word and Excel files describing the DNC campaign strategy and selling them to Trump.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Most of the sensitive data in every corporate network will be found in Office documents. Office offers encryption but the features are really difficult to use and the CRM system Microsoft offers, well Robert Snowden can explain why that is a problem.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Threshold decryption allows encrypted documents to be shared and used with exactly the same ease as unencrypted documents, somewhat easier in fact as there is less need to be concerned about leaks on stolen laptops etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice creates a group '@groupw', she encrypts some documents to the group but nobody can decrypt them at this point. Alice adds Bob and Carol to the group, now they can read the documents. Bob is replaced on the project by Doug, Bob's decryption authorization is cancelled, Doug is granted one.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice can change the ability to read the docs without changing any of the docs themselves. Alice can even manage a group she is not a member of without having access to the docs. The cloud service key manager can enforce the decryption policy but cannot decrypt.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2) End to end secure Password vault</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One of the main reasons password leak in enterprises is that they are written into shell scripts which end up either being uploaded to GitHub or being pulled off recycled hard drives.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Providing a secure and simple way for a script to pull a password from a cloud key server allows this vulnerability to be closed.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3) Configuring devices for developer use.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If we are going to achieve endpoint security, we are going to need to get to a position where all code of all types is signed. For this to be possible, it has to be easy for Doug the developer to provision the private keys he needs. For a C# developer, that means keys for:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) SSH - to connect to git repositories</div><div class="gmail_default" style="font-size:small">2) OpenPGP - to sign updates to the git repository</div><div class="gmail_default" style="font-size:small">3) S/MIME (i.e. PKCS12) - to sign the actual code</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">That's quite a few keys, but wait, there's more. If we want to do the job really right, we need to credential them all and preferably under a single authority. Oh and we would want every device Doug uses to have separate keys so that we can determine whether an upload came from a device known to have been compromised.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The Mesh provides a tool for this and also a means of credentialing all those keys to Doug's personal root of trust which is also bound to the registration record Doug created when he registered his callsign @doug.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Note that supporting the above features requires a messaging system. But the Mesh messaging system is intentionally limited to messages of 32KB (allows control of certain DoS vectors, avoids blocking). So it is not a direct replacement for SMTP. That is not its function though.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A better Mail mousetrap<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The key to taking over the mail apps space is to offer an open messaging scheme that anyone can start using and offers immediate benefits. What benefits do I mean?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Email address portability</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Mesh messaging does allow use of RFC822 style user@domain email addresses but those really aren't good. Unless you own the domain portion, its not your email address, it belongs to whoever provides the account. It isn't portable and there is really no way to use it as an end-to-end secure user identifier because the user of <a href="mailto:alice@example.com">alice@example.com</a> can change from one day to the next and there is no way for the sender of an email to know if this is a security concern to them.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Mesh callsigns belong to the user and are for life. So @alice means the first Alice who registered the name and always will (unless the name is transferred but this is a visible process giving the reason for the transfer).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice can change her service provider at any time but she keeps her callsign because that belongs to HER, not the service provider. It is bound to HER root of trust.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2) Unlimited size messages</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">SMTP is a push protocol. Every message is pushed to its destination. Which means services have to limit the amount of data users are allowed to send. The Mesh messaging scheme is also push but a Mesh message can contain a link giving the address from where the bulk of the message is pulled. Thus limiting messages to 32KB is the key to allowing payloads of any size to be sent. If someone sends me a video to edit in Premiere, I can download it on the desktop I use for video editing, I won't be downloading it to my watch.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Creating a protocol from scratch allows the client baseline to define the markup for rich text, one that actually supports annotation in a non-stupid fashion and one that is supported with consistency (so no more complaints from people using email clients that can't grock the HTML produced by gmail, etc.)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3) Eliminate the worst types of spam</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I get so tired of people whose response to my point that we can eliminate 99% of spam is to respond in the most jerkish, sneer possible, 'but what about the other 1%, what about that eh? eh?).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Every Mesh message is signed by the sender and the service provider transmitting it. Every Mesh message is subject to access control at the receiving service and in the client.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">No, this does not absolutely guarantee there is no possibility of an issue. But it does absolutely and totally stop anyone but my CEO sending a Mesh message that my email client will present as coming from him. Only messages from inside the company will be on company letterhead and this is all cryptographically enforced and certified.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I may accept contact request messages from random people but those are the only messages I will accept from unknowns. Lewis Hamilton should be able to put @lewis_hamilton on his business card and anyone from @toto_wolf to a 16 year old fan will be able to send him messages. But only authenticated messages from @toto_wolf are going to cause his cell to ring at 2am because there is really important information Lewis needs to know. And that contact request from that teenager will be handled by his fan club organizer.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Default deny is a powerful setting. Only people who are known and trusted are allowed to send links to executable attachments, etc. etc.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Contact request messages, aren't allowed to contain formatted text or links of any kind.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><div class="gmail_default">4) The same identifier works for voice, video and chat.</div><div class="gmail_default"><br></div><div class="gmail_default">Or at least that is the plan.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">5) All messages encrypted end to end with ends defined by the identifier used.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So that if the enterprise mail server is breached, the mail is still secure end to end.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">No, Alice does not send a message to 'Bob'. Alice sends a message to</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Her friend Bob she has known for 40 years and is having an adulterous affair</div><div class="gmail_default" style="font-size:small">* Her co-worker Bob she is working with on a project</div><div class="gmail_default" style="font-size:small">* Her bank manager Bob she is asking for a loan.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Even if it is the same Bob in all three cases, the encryption needs are very different because the data survivability criteria are different in each case. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">(Oh and sorry for breaking the news that Alice and Bob are cheaters, but why else would they have been so consumed by their need for secret communications over the years?)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So Bob's personal callsign is @bob but when he is working for @corp he is bob@corp and when he is a loan officer bob.loan@corp.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Same person, different contexts, different data owner, different callsign.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We can make this work if we have the will to do so. The first gen release of the Mesh tool is (intentionally) not very exciting because the worst thing would be to launch and then discover that the server capabilities aren't being encrypted (or such).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">It is an open system designed to be open from the ground up. That is how it will spread. I do not expect people to be putting their Mesh callsigns on their business cards for some time. The first use of the Mesh is going to be inside the enterprise.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">SMTP is going to be the only player that can provide full anyone-anyone mail connectivity for at least a decade. Enterprises won't be deploying the Mesh to replace email for their external communications. But replace SMTP for internal communications? Hell yes, becoming a no-brainer. SMTP is just too insecure to risk.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Now consider the case where I am doing one of my expert witness gigs and the lawfirm has the Mesh deployed internally. "Do you have a Mesh callsign?", "yes", "OK attaching you to the case group". And best of all, no need to worry about deleting confidential docs after the case is over, they just take me off the group. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Just finishing a few things up...</div></div></div></div></div></div>