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

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Sep 2014 12:51:27 -0400

[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: [email-masked]' The encryption key of the NSB spam filter.
NSB Alice key: [email-masked]' An endymail key for Alice, the
decryption key is on all her devices.
NSB Alice confidential key: [email-masked]' An endymail key for
Alice, the decryption key is only on her phone.
Personal Alice Key: [email-masked]' 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.

---

From: Leo Vegoda <[email-masked]>
Date: Sun, 28 Sep 2014 07:59:04 -0700

Hi Phillip,

On Thu, Sep 04, 2014 at 12:51:27PM -0400, Phillip Hallam-Baker wrote:

[...]

> PKI which for the purposes of this discussion we can consider to last

Does this mean that each person needs to create a key that will
remain cryptographically secure for the duration of their life? Is
it practcal to expect a key created today to be cryptographically
secure in 2074?

Separately, how practical is it to expect non-geeks to keep their
private key safe but accessible when necessary for multiple decades?

Regards,

Leo

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 28 Sep 2014 11:21:46 -0400

> it practcal to expect a key created today to be cryptographically

No, the expectation is not that the key will be secure lifelong. The
point is that the architecture does not assume that problems can be
solved by waiting for it to expire.

Assuming email certs expire annually really sweeps most of the hard
problems under the rug while making the system unusable.

Obviously, there has to be a key succession scheme. But checkpointing
the keys in a Trans like architecture allows a lot of problems to be
avoided. The transition scheme would be something like, generate the
new stronger key, sign it with the old, get the transition statement
notarized in the Big Log.

> private key safe but accessible when necessary for multiple decades?

Quite practical if the problem is posed in that way.

First, lets reduce the problem by encrypting the private key and
storing it in the cloud. Now all we need to do is to manage the
decryption key, which is a lot fewer bytes.

We can print that out on paper. We can do key splitting into 2 shares
or 3 of 5 or whatever.

The part I have not worked out yet is how to manage escrow of
decryption keys. Which is an essential requirement that is in conflict
with other requirements. It is easy enough to make a scheme escrowed
or escrow free. What is hard is to allow the user to easily choose
between them.

---

From: Natanael <[email-masked]>
Date: Mon, 29 Sep 2014 14:56:15 +0200

> or escrow free. What is hard is to allow the user to easily choose

Don't escrow private key material. Allow for specification of which
entities that have the authority to declare a new key as the successor of
your previous one, and conditions such as n-of-m chosen entities is
required and that the declaration must be put in that Big Log.

I've got a bunch of other ideas of this kind I'm going to write down in a
long email to these crypto related lists soon-ish.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 29 Sep 2014 09:09:01 -0400

On Mon, Sep 29, 2014 at 8:56 AM, Natanael <[email-masked]> wrote:
> Don't escrow private key material. Allow for specification of which entities
> that have the authority to declare a new key as the successor of your
> previous one, and conditions such as n-of-m chosen entities is required and
> that the declaration must be put in that Big Log.

If you want regular people to use end to end encrypted email, the risk
that they lose access to their data and their pics is vastly more
serious than the risk of government intercept.

What I did think of though was a scheme where the private keys are
stored in a 'deniable' format.

So lets say that we generate a key pair, ke, kd, an identifier I and
recovery code R.

We store pairs  [I, E( kd, R)] in a hash database. to recover the
data, the client presents I and gets back E(kd, R).

We can form I at random or we can derive it from the recovery code I = H(R).

Point is that we can't know whether or not kd is escrowed. It may be
but it might not.