Subject: [Endymail] Why S/MIME and OpenPGP ecosystems fall short

From: Watson Ladd <[email-masked]>
Date: Mon, 1 Jun 2015 22:07:11 -0700

Dear all,
Let's compare a messaging system like TextSecure to the experience of
secure email messaging. A user downloads TextSecure, starts using it.
It has a familiar UI, and encrypts when it can without any explicit
user invocation. If they want to validate keys, they can do so easily:
there is one fingerprint and clear instructions on how to compare it.
The semantics are exactly what is expected.

Compare to what happens with GPG. Immediately the user is asked to
make important choices with no guidance. Key discover is separate
step. When sending messages, they have to choose several orders of
operations and ciphers, with the wrong choice having consequences. I
don't think any choices have the right semantics. A lot of this has
been ruled out of scope as UI issues, but I don't think so: I think
that solving these issues require removing many of the problems that
we expose to users. Certainly some plugins do a very good job of
fixing some of these headaches, but I don't think any of them are as
reliable as TextSecure.

It's clear to me that this isn't easily fixable by standards work
alone: much of the damage is baked in to the functioning of S/MIME and
PGP. What needs to happen is that we need to come up with good ideas
around key management that are actually deployable, and provide the
semantics people want.

Sincerely,
Watson Ladd

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 2 Jun 2015 09:49:00 +0000

Agreed. But: Good luck. The GPG fans will fight you every step of the 
way.

Arnt

---

From: Tom Ritter <[email-masked]>
Date: Tue, 2 Jun 2015 21:28:07 -0500

I'm a big fan of TextSecure, but comparing TS and Email ignores many of the
difficult problems TS has been able to dodge that email cannot.

The biggest one I'll put forth is Key Authenticity[0].  I'm not talking
about the fingerprint comparisons (they're about the same there.) In TS, I
ask the central TS server "What's the key for Watson Ladd <1 555 123 4567>"
and it gives me a key that I can reasonably believe is yours. TS is the
central authority.

Email's central authority would obviously be federated at the provider, but
now we're gated on our email providers supporting some sort of Key
Directory. Google and Yahoo are going to do this, but that doesn't solve
the problem for everyone. This was solved for DNSSEC with the DLV - a
central authority everyone agreed was able to provide you with a server's
keys. Who will be the Email Lookaside Vector? Who will everyone agree to
trust?

There are other very difficult problems TS dodges, but an email solution
must confront immediately.  To be honest I'm not entirely certain TS'
current mechanism for resolving some of these, maybe someone more familiar
with TS' implementation can comment?

- Multi-Device. TS is by-and-large single device. I thought at some point
they had support for multi-devices - and I thought that worked by me giving
the central directory multiple keys, and senders encrypted to all of them.
I assume the central directory authenticated the user using the user's
phone number.

When people envision seemless email encryption they usually envision it
detecting that the recipient has a key and either prompting the sender to
encrypt or just encrypting automatically.

- Privacy. TS sends your entire address book to the server and tells you
which contacts have TS. Are we going to do this for email? Or are we going
to do per-email queries? How does it handle the "user is composing offline"
case?  In TS, you can't send a message to someone who doesn't have a key -
that problem doesn't exist.

I'm confident there are others, I half-composed a few more, but I'll leave
them to another time.

On 2 June 2015 at 00:07, Watson Ladd <[email-masked]> wrote:
> alone

I agree.

> much of the damage is baked in to the functioning of S/MIME and
> PGP.

I'm not sure I agree with this point though.  PGP at least is flexible
enough that you don't care about interoperability, you can select a subset
of functionality and build your system on top of that.  And then if you
reach critical mass, you can make people want to interoperate with *you*.
Which is basically what Google did, Yahoo followed suite, and if they
succeed as much as they wish to - we will in turn follow.

> What needs to happen is that we need to come up with good ideas

I agree-ish.  I think we need to come up with good implementations and user
experiences of key management - not just ideas.

-tom

[0] I say Authenticity instead of Discovery, because one can reasonably
point to a Keyserver and say "Discovery is solved."  But the on the scale
of Authenticity, keyservers have zero, and a central directory has "some,
but not all".

---

From: Michael Kjörling <[email-masked]>
Date: Wed, 3 Jun 2015 09:59:17 +0000

> fixing some of these headaches, but I don't think any of them are as

I have absolutely zero experience with TextSecure so cannot compare
against that, but are you talking about the _protocols and standards_
(OpenPGP) or the _implementation_ (GnuPG, PGP) in the above? GnuPG is
somewhat technical, but OpenPGP does not have to be exposed that way
to the user.

We can fix the _implementation_ by making sure the defaults offered
are reasonable and secure (according to current knowledge, adjusting
over time as necessary and maintaining a margin for error) and adding
a very first step asking whether the user wants a simple or advanced
key generation process. The simple process would use those default
values and only prompt the user for what is specifically needed
(perhaps only their name, email address and desired passphrase); the
advanced process would allow the user to select algorithm, key size,
etc just like the normal key generation process in GnuPG does today.
This would be reasonable because _the defaults should already be
reasonably safe_; if they aren't, then they should be adjusted.

The simple process could even start out by generating a small,
throwaway key pair (say, perhaps, a 256-bit RSA key pair) with a short
generation wallclock timeout _to determine the system's performance_
and adjust the key length to be generated upwards if the system is
fast enough to handle generating and using a longer key pair. _For
example_, set the default to RSA encrypt+sign with a 2048 bit modulus,
but if the system is fast enough to _generate_ a 256 bit RSA key pair
within, say, 200 ms, _then_ use 3072 bits instead; if 100 ms, _then_
4096 bits instead. (Modulus lengths and timings are arbitrary and for
example purposes only.) This will allow the software to gracefully
move toward longer keys when the system is fast enough to handle them,
without needing modification later, at the cost of a small amount of
entropy (which could in principle be fed back into the system PRNG).

With something like that, we remove at least _one_ of the major
obstacles you (quite rightly) point out, namely the user immediately
being confronted with the choice of (in my case) RSA/RSA
(sign/encrypt), DSA/ElGamal, DSA (sign only) and RSA (sign only),
followed by picking a key size. If the current defaults (with GnuPG,
dual-use RSA 2048 bits modulus) are reasonably sane then regular users
don't need to be confronted with those choices and we don't compromise
security compared to today, yet power users can be given the
opportunity to shoot themselves in the foot (or pick a higher degree
of security at the cost of some performance).

This doesn't solve key distribution and discovery, but it should solve
at least one part of key generation.

-- 
Michael Kjörling • https://michael.kjorling.se • [email-masked]
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 4 Jun 2015 18:19:07 +0000

If you have zero experience with textsecure, I suggest that you get 
some before you continue to talk about these things. Because textsecure 
is a messaging system with good crypto and good deployment, and that is 
rare enough to be worth learning from.

You cannot just say that 
textsecure ignores something and silently assume that that thing must 
be done, solved or supported: maybe ignoring that is precisely the key 
to wide deployment.

Arnt