[Endymail] How an endymail eco-system might incorporate web of trust features

[Phillip Hallam-Baker <[e-mail]>]

[We don't have a name for the person sending Alice spam, I suggest Spaulding]


As I see it, we are a long way away from deciding on a trust model. If
in fact we ever do chose the one perfect trust model. But it does keep
coming up so this is the way I think web of trust models and TTP
models might interact in an endymail ecosystem.

First off, I assume that each participant has at least one personal
PKI which for the purposes of this discussion we can consider to last
their lifetime.

[In practice of course some people will have more than one, some
people will screw up and lose control of their master secret, some
people will go into witness protection programs, etc. etc. But the
starting point for sanity is that we don't force unnecessary changes
onto people.]


One of the core principles of PPE is that sending encrypted mail is as
easy to do as sending regular mail. So there is a usability layer on
top of the raw crypto. But in order to set up the requirements for
that usability layer I have to first explain the security requirements
in raw crypto. So please suspend disbelief for the usability side of
things as you read, it will become clear as we go along.


So Alice has her personal PKI and the phingerprint of her master key,
how might someone use that to communicate with Alice?

The first point of departure from conventional PKI is that how Bob
communicates with Alice might not be the same as how Carol
communicates. Alice and Bob have known each other 40 years now. They
are very very good friends. So I think it rather likely that Alice
would be prepared to whitelist Bob as not a spammer. Also they spend
so much time exchanging secret info, Alice is probably rather more
concerned about the confidentiality of her emails from Bob than from
Carol. And as for Spaulding, she does not want him to be sending
endymail at all.

So lets imagine Alice has a couple of laptops, a mobile phone, a
couple of tablets and three desktops she has configured to read mail
from. And now lets imagine she works for the National Security Bureau
(NSB) which is the little heard about US agency charged with
competently keeping government secrets secret. Does Alice really want
every one of those devices to be able to read her Tippy-Top Secret
messages? I think not. But she wants to be able to access 'Somewhat
Secret' messages on all of them.


So in practice Alice has the following mail confidentiality
configuration, some of which is configured for her by her employers at
the NSB and some of which she has set up:

NSB Bulk Key: '[e-mail]' The encryption key of the NSB spam filter.
NSB Alice key: '[e-mail]' An endymail key for Alice, the
decryption key is on all her devices.
NSB Alice confidential key: '[e-mail]' An endymail key for
Alice, the decryption key is only on her phone.
Personal Alice Key: '[e-mail]' An endymail key Alice uses for
personal correspondence.


Only some of these keys are publicly visible. And use of certain keys
likely requires a message to be signed and meet specific access
controls.

Alice has four keys but only three accounts. This is because the
choice between using the NSB bulk key and the NSB alice key can and
therefore MUST be taken by the infrastructure. A mail sender knows if
they have been pre-approved to send endymail or not. The choice of
using one of the other accounts has to be left to the sender because
they have distinct semantics. Bob knows that sending a message to
Alice in her NSB role is different to sending her personal mail. Hence
a different account is required.

In other words, we are using three different email accounts to
represent three different email security policies.


Alice has four mail accounts but only one life long phingerprint. And
that phingerprint could in theory be used with any of her email
addresses. If Bob wants to be absolutely sure that the message goes to
Alice he should be using her phingerprint.

But this is not the only consideration. If Bob is sending a message on
official business he would be at least as concerned that the message
is going to someone who is currently employed at the NSB as that it
goes to Alice. So in this case it is more appropriate to use the
phingerprint of the NSB to determine the governing policy.


Authenticating organizations such as the NSB or banks is something we
already have an infrastructure built out to perform, its the WebPKI. I
would very much like to go further and make use of PKIX logotypes and
EV certificates with authenticated logos inside them to really nail
down this relationship.

Authenticating Alice in her personal capacity is rather more
challenging. This is because corporations are not people, they only
exist through government action. Thus government issued credentials
are perfect for authenticating them. People do not exist as a result
of government action, government credentials can be forged and there
is a vast underground industry dedicated to forging them.


Many people do go through events where we might potentially checkpoint
their credentials however.

Let us imagine that Alice creates her personal PKI at 18 when she
starts college. Her name at this point is Alice Splunge.

The college issues her an email account and she creates an encryption
key to use with it. The college provided PKI gateway issues her a
certificate in the college hierarchy and checkpoints it against the
global TRANS notary infrastructure.

[Note here that the use of the definite article in talking about
catenate notary infrastructures is  a recognition of the inevitability
that there can be only one. Wherever there are two infrastructures it
is inevitable that data objects from infrastructure A will be cross
registered in infrastructure B and vice versa. And it is mutually
beneficial that they do. And when they do so the two infrastructures
become equivalent in terms of trustworthiness]


At this point we have an assertion about the identity of Alice that
might have been forged very cheaply when she was a student in 1984.
But an attacker who decides that they want to impersonate Alice today,
30 years later would need a time machine or a way to break the
encryption. The work factor for an attacker goes to essentially
infinity after the notarization takes place.

So it is my belief that we will establish a significant population of
people with keys that have been enrolled in a notary service at some
point in the past and this will create a significant work factor for
an attacker trying to impersonate one of those people. Many of those
users will have keys that have been enrolled numerous times.

We are not going to get 100% coverage this way but we can probably get
to 10% without too much difficulty.


Now lets imagine I am one of the 90%, how do I get a key established?

One way would be to find a member of the 10% and get them to endorse
my key. Or better find several members.

Here is how endymail is a huge advance on PGP. In the PGP web of
trust, who you get endorsed by determines who you can communicate
with. If you live in Kansas then it is highly unlikely you will find a
trust path to someone in Siberia.

This limitation goes away in the endymail scheme because the attacker
can't feasibly impersonate a 30 year established key.

An attacker can be a person with a 30 year established key but making
fraudulent or negligent endorsements opens them up to accountability.


As for mechanisms for endorsement, QR codes are only one mechanism
that might be used. It is a pretty good one however.

I recently bought a cell phone for my children. $5 each. They have two
cameras. I don't see getting a smart phone would be an unreasonable
requirement for endymail even if it was essential but it isn't.



The way I see endymail working for an end user is that their mail
client would have the following as information stores:

1) Contacts directory with entries for strong email addresses (i.e.
address plus phingerprint) of people I know

2) A Web Service provider chosen by the user that provides key
discovery services.

3) A local cache of previous queries to the Web Service (including
negative results).


The email client is going to periodically scan its contacts directory
to attempt to pre-fetch keys. This activity improves performance and
reduces the value of traffic analysis.

Whenever an email message is sent, the client attempts to apply
encryption if possible. This means:

1) It can find an endymail encryption key for the recipient.
2) The recipient has asserted that they prefer mail encrypted.


The key discovery Web Service is going to be accumulating information
from multiple sources:

1) The notary service log files
2) Public directories (possibly including DANE)
3) Policy information taken from SMTP headers.


One of the big problems a lot of people seem to have is distinguishing
the risk introduced in a 'first contact' situation from future risks.

Imagine that we have a large square sheet of plywood, 2 meters on each
side and a hole 2cm in diameter in the middle. The plywood is held
roughly horizontal by a series of motors that are tilting and twisting
it constantly causing several thousand marbles 1cm in diameter to roll
across the surface.

Given that set up it would probably take a very long time for the
marbles to all drop through the hole. Now rout some channels in a
spiraling pattern ending at the hole into the plywood. The marbles
drain a lot faster.

The point here is to capture as much Internet email traffic as
possible and put it on rails that guide it to the endymail hole.