Subject: [Endymail] What are the problems?

From: Watson Ladd <[email-masked]>
Date: Sun, 7 Sep 2014 10:55:46 -0700

Dear all,
Let's back up from spam.

If we look at E2E encryption, S/MIME is widely supported and deployed.
It's way more heavyweight than it needs to be. PGP same story, but add
in completely weird crypto. (I don't actually know what S/MIME does
cryptographically: my tolerance for ASN.1 is only so high) Both are
unnecessarily complicated. So why aren't they used more? I can think
of a few issues.

The first issue is UI: nothing much we can do about it here. But if we
reduce the complexity of the protocols by subsetting them, the UI
doesn't need to expose so much, and so conceivably be simpler.

The second issue is multidevice usage. Here we have questions about
transporting keys, removing keys from devices (hard), but the core
protocols will work.

The third issue is webmail: I'm part of the problem here, but I think
browser extensions (ugh) can solve it: I don't think we need new
protocols.

The fourth issue is key discovery. For S/MIME I don't know how this
works. For PGP the keyservers work, but the control ensuring you get
the right key is the WoT, which is very hard to use, and most people
don't do it. In practice the keys get put on websites served over TLS,
or tweeted.

We should really think about the merits of the Public File: it's very
close to what we have with PGP, and would resolve a lot of concerns
about CA subversion.

Sincerely,
Watson Ladd

---

From: Elijah Sparrow <[email-masked]>
Date: Sun, 07 Sep 2014 11:16:33 -0700

> Let's back up from spam.

I have attempted to enumerate the major issues involved in end-to-end
email in this report:

https://github.com/OpenTechFund/secure-email

It also includes a brief summary of each of the major projects working
on 'new generation' end-to-end encrypted email (in general, these
projects all seek something less difficult, more automatic, and
sometimes with greater security than existing openpgp or s/mime).

Phillip may note that the report does not include PPE. I haven't had the
chance to update the report with a PPE entry since PPE was posted. Pull
requests welcome.

The darkmail entry is also out of date, now that they have a new
architecture.

-elijah

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 7 Sep 2014 22:21:08 -0400

> doesn't need to expose so much, and so conceivably be simpler.

While S/MIME is horribly complicated to implement, thats not the cause
of the UI disaster.

The implementation complication is due to the use of ASN.1 which is a
nightmare to program and if you do it the usual way requires a
monstrously complex compiler with a big obese run time.

But all of that bit is hidden from the user.

> transporting keys, removing keys from devices (hard), but the core

This is the part where the legacy code is just insane.

With PPE, all you do to configure Windows Live mail to accept
encrypted mail is run the key generator and post the file it generates
to a Web site. If you give it the domain of a crypto service then the
service will do the post to a web site for you as well.

Without PPE what you have to do is
* Find a CA
* Find the S/MIME page at the CA site, fill in lots of forms
* Respond to an email challenge, here it is essential that you go back
to the CA web site with the same browser or it won't work.
* Start Windows Live Mail, find the security configuration tab on the account
* Tell Windows Live Mail to use the certificate

Thats ten minutes if you are lucky.

Now Thunderbird on the other hand you have all of those steps only you
also have to export the key and certificate out of your Windows
certificate manager and then import it into the Thunderbird key
manager as well.

On iPhone you can use S/MIME but the mechanism for importing a
certificate and key was documented nowhere I can find. I had to ask an
Apple employee. Apparently you send an email message to yourself with
the encrypted key attached. Then you can open the message and it will
import the key.

Again, this is a one button operation without Web service support and
only a little harder with web service support (and then only if you
are using the open source version of the code, I would guess if there
is a Comodo branded version of the key manager it will automatically
connect up to Comodo and so the user won't have to enter anything.)

Point is that there is absolutely no reason that the UI can't be
fixed. The failure is in the integration into the product.

It does not take a usability lab to spot these problems. They should
be obvious to anyone with a brain. The whole process is just makework
for the user.

Another big problem is that pretty much every multi-platform program
tends to insist on managing keys itself rather than using operating
features for the purpose. The inevitable result is a really shit user
experience and gaping security holes.

Windows and Mac both have mechanisms in place for protecting keys in a
user's account. So they don't need to enter a passphrase to read each
mail. Thunderbird tries to use its own and does a horrible job of it.

> browser extensions (ugh) can solve it: I don't think we need new

Well reading mail is easy enough, just pop out a viewer that pulls the
user's key from the machine keystore.

> _______________________________________________
> Endymail mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/endymail