[messaging] TOFU to ease PGP key discovery

[elijah]

On 02/09/2015 12:40 PM, Bjarni Runar Einarsson wrote:

> We considered something very similar to what Whiteout are doing, and
> decided against it for a few reasons. The main ones being:
> 1. Just because a user has a key in a key server, does not mean they
> currently can (or want to) read encrypted mail.

At LEAP, we faced this same dilemma. At first, we choose the Whiteout
path (always opportunistic if listed in keyservers) and then switched to
Mailpile (do not always send first email encrypted). We might switch
back. There may be some middle ground: if a key is of sufficient key
length, and updated within a recent window of time, then there is a much
higher likelihood that the user does in fact desire encrypted email. If
you look at the actual keys in the keyservers, a shocking number of them
are really old and 1024 bit RSA.

There are two failures: (1) the keyserver has the bogus key (2) the
recipient did not expect or desire encrypted email. I don't think #1 is
just a targeted attack, since probably some troll will soon figure out
how easy it is to fill the keyservers with imposter keys, for the lulz.
Until then, #2 is still a big problem. We will only enrage the user if
too many of their recipients can't read their mail.

On 02/09/2015 11:40 AM, Trevor Perrin wrote:

> Moreover, it doesn't solve the entire problem - if you want
> reliable automatic encryption, key lookup isn't just a *first* message
> problem, it's an *every* message problem, because keys change.

This is extremely important. Perhaps I should get this in tattoo form.

For the short term, it seems necessary and fine for TOFU to be part of
any automatic key management strategy. But this is just the first step,
the real question is how these keys are handled after the TOFU.

The rules LEAP is going by are described here:
https://pad.riseup.net/p/key-validation

On 02/09/2015 12:58 AM, Tankred Hase wrote:

> we've added HKP key server support to Whiteout Wail and have written a
> post about usability. Though I'd share it here:

Cool. We are playing with a similar system, although federated, where we
proxy HKP lookups, but return authoritative results for the home
provider (every LEAP-powered service provider runs a key lookup service,
and the response is authoritative for addresses owned by the provider
but proxied for foreign requests [with longish delay], and falls back to
HKP proxy cache if no better source can be found).

Those of us working on email are grappling with the same issues. Many of
the common issues relate to how different projects will interact with
one another. This list has had fruitful discussions on key validation,
but there are other important topics too, for example:

(1) Subject header. Ugh.

(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
(unless the provider is in the habit of uploading signatures to the
public keyservers). The OpenPGP header has the same problem. One
solution would be an "X-Provider-Key-Endorsement" header that allowed
the client to pick among well defined methods for retrieving a key
endorsed by the provider (could be super simple, like webfinger). A
universal system of key validation would obviate the need for this, but
until we all agree on a single standard...

(3) We need common practices for "verified key transitions".

(4) Metadata, mega woes. There are many approaches, but Pond's is
probably the best. The cool thing is that direct delivery to recipient
provider can be an opportunist option when the recipient supports it.
LEAP is one of the parties that will soon start on the PANORAMIX project
from George Danezis to develop and deploy a new mix network
infrastructure. We plan to use this for user -> server direct delivery
of email (in addition to server-to-server).

and so on...

-elijah