Re: [Endymail] Off we go...

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

On Tue, Aug 26, 2014 at 6:34 PM, Pete Resnick <[e-mail]> wrote:
> Hi all,
>
> We've got 88 people subscribed now, which is pretty quick for a list like
> this. Seems like there really is interest in the topic, which is good.
>
> What we'd suggest is to start off with some sharing about what folks
> are/have-been doing in this space. We know there are a range of projects and
> proposals and it'd be good to get some information/pointers on those we all
> know about.

My work is described on the PrismProof.org web site.

I have been looking at the reasons people don't use end to end
encrypted mail. I see the following problems:

1) Every system currently available has chronic usability problems.
They are too difficult to configure and too much hassle to use. This
is true of both S/MIME and PGP.

2) The standards battle between PGP and S/MIME has run into a
stalemate with no victor.

3) The CA trust model does not really deliver value for end entity
certificates unless the certificates are being issued by an LRA that
knows the key holder. The Web of Trust model does not scale due to the
Moore bound.


To illustrate just how unnecessarily hard it is to send S/MIME mail
today, this is what it takes to install a certificate in Thunderbird
on Windows.

1) Discover that the feature exists
2) Select a CA to issue the certificate, Comodo offers free certs but
you will only find them if you are looking for them.
3) Fill in a Web form to apply for the certificate
4) Respond to the email challenge
5) Install the certificate into the Windows keystore using the Web
browser but this will only work if you use the same Web browser as you
used to apply for the certificate
6) Export the certificate from the Windows store
7) Import the certificate into the Thunderbird cert store which is not
the same as the firefox one
8) Configure Thunderbird to use the certificate
9) Repeat this whole process every 12 months

And before you start off telling me about PGP, getting that to work
proved so tedious I gave up. The problem was that the client I tried
to use was from the 'mushroom' school of usability and does not tell
the user anything they need to know to use PGP. Not even their
fingerprint and not the key server they use either. And it insisted on
encrypting the key under a strong passphrase which is idiotic, it
should use the machine trust store.


I also have an existence proof for a solution to the usability problem.

The PPE key manager generates a personal PKI hierarchy and configures
Windows Live Mail to use it without any user intervention at all.
There are some things that I would like the user to be able to select
such as the choice of a service provider to gateway their key to other
forms of PKI.

Strong email addresses are conceptually just a PGP fingerprint bolted
onto the front of a regular email address. So we now have one
identifier that specifies the address to sent the message and the
means to validate the security policy under which it is sent. This
effectively enables the use of the de-facto PGP trust model of key
fingerprints in the S/MIME world.


The reason I am basing my work on S/MIME is that that is the standard
supported by all the mail clients. So building on that gives access to
a vast base of installed software. All we need to do is to write easy
to use tools to configure them. Or alternatively shame the providers
into fixing the absolutely dreadful usability of their current
product.

Lets get one thing straight, you don't need to have a usability lab to
spot these usability problems.


> Its probably worth stating now that this list is *not* intended to pick a
> winner amongst those, nor to anoint one as the "official" IETF thing, so
> luckily we don't need to have a bunfight about which is the shiniest
> proposal of them all. :-)

I disagree. I think the problem divides into two parts, how you decide
which key to use and how to apply that key to a message.

The first part is the area where I don't want to come to one agreement
because there isn't one single trust model that works for every
application. It is a research area where we can do some really
interesting things. This is the place where I think Certificate
Transparency like concepts really do pay off.

But innovating in the key selection space should not require people to
develop their own message format or embed it in MIME. We already have
that problem solved and deployed: S/MIME works great as a message
format and it has decades of testing in the deployed email
infrastructure and every email vendor makes sure that they don't break
it.


The biggest cost to me as a researcher in the key selection space is
having to 'enable' all those email clients. Which is why I want to
separate out the code into two parts

1) A Common core that goes in the client that has web services sockets
to talk to key services in the cloud
2) Key services in the cloud that do 'the interesting stuff'.

This is not going to be end to end security as people think of it on
day one. But this separation allows us to tweek the trust models and
update them without having to roll out new generations of email
clients. We only embed the trust model into the client endpoints after
it is proven to work.



> Success here will be when/if we identify some bit(s) of work that the IETF
> could credibly do that'd improve the real-world end-to-end security and
> privacy of email. And note that "credible" there requires stuff to be both
> technically sane and to have a sufficient set of capable folks interested
> and willing to do work.

Defining a common platform on which we can build new trust models
would be one of those bits of work: