[Cryptography] My deployment plan for end-to-end secure email.

[Phillip Hallam-Baker]

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.

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.

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


So my starting point is a set of three problems which affect small but
dedicated communities.

1) Data at rest

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.

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.

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.

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.

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.

2) End to end secure Password vault

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.

Providing a secure and simple way for a script to pull a password from a
cloud key server allows this vulnerability to be closed.

3) Configuring devices for developer use.

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:

1) SSH - to connect to git repositories
2) OpenPGP - to sign updates to the git repository
3) S/MIME (i.e. PKCS12) - to sign the actual code

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.

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.

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.


A better Mail mousetrap

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?

1) Email address portability

Mesh messaging does allow use of RFC822 style user at 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 alice at example.com 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.

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

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.

2) Unlimited size messages

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.

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

3) Eliminate the worst types of spam

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

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.

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.

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.

Default deny is a powerful setting. Only people who are known and trusted
are allowed to send links to executable attachments, etc. etc.

Contact request messages, aren't allowed to contain formatted text or links
of any kind.

4) The same identifier works for voice, video and chat.

Or at least that is the plan.

5) All messages encrypted end to end with ends defined by the identifier
used.

So that if the enterprise mail server is breached, the mail is still secure
end to end.

No, Alice does not send a message to 'Bob'. Alice sends a message to

* Her friend Bob she has known for 40 years and is having an adulterous
affair
* Her co-worker Bob she is working with on a project
* Her bank manager Bob she is asking for a loan.

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.

(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?)

So Bob's personal callsign is @bob but when he is working for @corp he is
bob at corp and when he is a loan officer bob.loan at corp.

Same person, different contexts, different data owner, different callsign.


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

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.

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.

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.


Just finishing a few things up...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210822/e61d5316/attachment.htm>