[messaging] TOFU to ease PGP key discovery

[elijah]

On 02/10/2015 03:30 AM, Mike Hearn wrote:

>     (2) We need a new protocol that allows a sender to advertise to the
>     recipient what their key is and that they prefer encrypted email. The
>     email signature is a good signal, but not ideal because there is no real
>     binding between the fingerprint on the signature and the email address
> 
> I hate to sound like a broken record, but if you decided not to encrypt
> all mails by default but rather trigger it off a signed message ....
> then you have the S/MIME model and your above problem only exists due to
> the insistence on using PGP. 

Except that this is our degenerate case, not our only case. But your
comment is really about OpenPGP versus S/MIME, so let us recap:

S/MIME has a single tantalizing feature: a very large installed base of
compatible MUAs. But it also only supports public key validation via CA.
Two interesting proposals have taken the defensible position that we
should use S/MIME to encrypt as much email as possible now and forgo
validation in most cases (http://www.prismproof.org and
https://github.com/tomrittervg/uee).

The defensible position taken by all the other new email proposals is
that user keypairs must be automatically generated and automatically
validated. Although most of the projects do not currently support
automatic validation, all plan to.

If Let's Encrypt starts offering signatures on user certs that can be
automatically acquired via a mail-back API, then using S/MIME could
certainly fit within this auto generate and auto validate model. But the
current system, where obtaining a user x.509 cert is costly and/or
onerous, is not probably not the basis for a viable model of opportunist
encrypted email unless one chooses to skip validation.

> If you want to try it out, grab a free cert here
> https://www.comodo.com/home/email-security/free-email-certificate.php

In my mind, this would be an example of onerous: max key size of 2048,
limited to personal use, requires a horrible legal agreement, not
automated. I think it is unlikely that any opportunistic email
encryption project would feel comfortable betting everything on the hope
that a CA will continue to offer "free" user certs. If Let's Encrypt
does offer user certs, then this approach would be much more sound.
Anyone know if this is in the roadmap? Are Seth or Peter on this list?

> What's more - existing mail clients already have the behaviour you're asking for! There is no work to do!

It is not the behavior that anyone wants, it is just the worst case fall
back scenario for both Mailpile and LEAP (aside from pure cleartext, of
course). Also, the user experience of S/MIME without CA in actually
existing MUAs is sorely lacking on many fronts.

> There /is/ a standard for all the things you are asking for. It is
> specified by the IETF. It has protocols for verified key transitions and
> more. It's widely deployed and implemented. It's just not PGP.

This is a common refrain, but I think an oversimplification. There are
four options if the goal is to propose a new approach to making
encrypted email easy and common:

(1) S/MIME, perhaps as proposed by the aforementioned PPE and EEU.

(2) OpenPGP, the approach taken by Whiteout, Mailpile, and Bitmask (LEAP).

(3) OpenPGP-like. For example, OpenPGP but with 25519 for signing and
encryption.
    This is the approach taken at one point by e2e, maybe still?

(4) Something new. This is the approach taken by all the p2p approaches,
as well
    as DIME (Darkmail) or the idea of Axolotl for email, for example.

I don't think any of the people working on any of the new email projects
would say that there is a clear winner here. Each option has certain
advantages and also serious drawbacks.

I am as forceful a critic as anyone when it comes to the current user
experience of OpenPGP, but as a technology it supports many of the core
semantics that many of us want, like subkeys and the ability to manage
multiple signature endorsements of a public key. It also has mind share,
which is a not an insignificant consideration. You would be hard pressed
to leak something to Glen Greenwald using S/MIME.

-elijah