[messaging] TOFU to ease PGP key discovery

Bjarni Runar Einarsson bre at pagekite.net
Mon Feb 9 12:40:10 PST 2015


Hi Trankred, everyone!

As a counterpoint, I wanted to briefly discuss Mailpile's take on this.
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. In particular, many
users depend on being able to read incoming mail on mobile devices.
Sending them encrypted mail by default would just piss them off. Our gut
feeling was that automatically encrypting mail would prove to be so
annoying and inconvenient, that people would angrily switch mail clients
after just one or two critically important messages were transparently
rendered unreadable by the auto-encryptor. People respond very strongly
to social cues, so if your mail client makes you look bad to your peers,
you'll switch in a hurry. At best people will turn the auto-encryption
off, thus rendering the whole exercise futile.

2. As has been mentioned, we feel protecting the user's social graph is
just as important as protecting the contents of their messages.
Constantly querying key servers (centralized or otherwise) leaks a lot
of information, as does the traditional PGP model of signing keys and
publishing the result for the world to see.


Those are the constraints we're working with, and they are admittedly to
a large degree based on our gut feelings and anecdotal evidence, not
hard data. I find it very interesting that Whiteout have taken a
different approach - if it works well, that probably means we've been
overthinking things here at Mailpile. Also, hats off to Whiteout for
shipping things. We're still struggling to release something usable, in
part because we made choices like this one. :-)

Mailpile also want to make it easy for users to encrypt and when
possible we would like to do so opportunistically as well. The approach
we are working on for achieving this, is roughly as follows:

Key discovery: Our preferred method for key discovery is to look in the
users own received mail (using Mailpile's built-in search engine). So
when the app needs to encrypt to someone for the first time, we first
check whether we've got a public key for that recipient in our mail
store already. To seed this (and to signal that we can accept encrypted
mail), Mailpile puts OpenPGP headers in all outgoing mail and
opportunistically attaches our public key. This would be the only key
discovery method used for opportunistic encryption.

Manual key discovery: When a user wants to encrypt to someone they
haven't encrypted to before, the key searching tool checks local mail
first, and then goes to HKP servers etc. To protect the user's privacy,
we plan to route such queries over Tor as much as possible/safe. Keys
are ranked by a few metrics (key size, creation date, etc.) and
presented to the user to make a choice. The user can also copy-paste
keys or URLs to keys, or upload files from disk.

Trust: Like Whiteout, we assume a TOFU trust model. Users can verify
keys by hand and we provide tools with which to do so, but we ignore the
web of trust. Once a key has been chosen for a recipient using one of
the above strategies, that choice is recorded in the address book and
isn't automatically reevaluated unless a key is close to expiring or we
receive as an attachment a new key signed by the old one.

Opportunistic encryption: We plan to again leverage the search engine,
to perform a historic analysis of the mail we have received from the
recipient of outgoing mail. If the recipient always (within a certain
window of time) sends a signal implying their mail client supports PGP
(key signals: signing mail, OpenPGP headers) and we have a key for that user, Mailpile will consider encrypting by default to that recipient.

User preferences: Each contact in the address book has a crypto
preference. The default setting is to use the above heuristics, but the
user can at any time force encryption on or off for a given recipient or
change keys, and those settings have priority.

User interface: In the event that someone sends us mail we can't
decrypt, the app detects that and suggests solutions - including making
it easy to send back a reply including the correct public key.

Note that this is the design we're aiming for - not all of this stuff
works yet. Also, this is written from memory, so I am probably
forgetting something. Hope this is useful to someone! Comments and
feedback welcome.

Cheers,
 - Bjarni

-- 
Sent using Mailpile, Free Software from www.mailpile.is
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP Digital Signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150209/083fb424/attachment.sig>


More information about the Messaging mailing list