[messaging] TOFU to ease PGP key discovery

[Daniel Kahn Gillmor]

On Mon 2015-02-09 09:03:37 -0500, Tankred Hase wrote:
>
> If I understand the HKP protocol correctly this gives us the most
> recent key. I've tested this and have thus far received a sane
> response in most cases. E.g. I'm using Whiteout Mail right now and got
> the following key for you:
>
> E64F 19EB BBE8 6AA9 7AF3 6FD5 1104 4FD1 9FC5 27CC
>
> I agree that this will not always work though. Specifically if someone
> uploads a fake key for you.

Yes, most modern keyserver implementations (sks in particular) return
the OpenPGP certificates sorted by creation date of keys.

But there is no guarantee that the particular keyserver you end up
talking to will be (a) running SKS, (b) uncompromised.

> I'm not sure if the HKP servers use certain heuristics on their side
> to decide which key to give me (e.g. the key with the most
> signatures).

they do not.  If they did, the heuristic "most signatures" is just as
easily spoofable in the current scenario as the heuristic "most recent
creation date".

> But according to the threat model we describe in our blog, this is
> regarded as a "targeted attack". To correct this users can manually
> lookup keys in the contacts menu in Whiteout Mail.
>
> In the user-labs we have conducted internally, this has worked well
> enough up until now. Our findings were that non-pgp users that are not
> very tech-savvy were able to send encrypted mails to experienced GPG
> users without having to fully understand how things work under the
> hood.
>
> Like the post states there is obviously a trade-off in terms of
> security here, but the goal with our approach is to get new users
> using PGP that would previously have failed with something like
> GPGtools or Enigmail. This is also the market we are trying to address
> right now.

I think this opportunistic approach is certainly better than the
existing approach -- but i would recommend the opportunistic approach
not be presented as "a way to get the right key", but rather as a
default mechanism to get *a* key.

Also: have you considered the additional privacy concerns that might
arise when sending mail to someone without a key?  That's the part
that's often gotten me tripped up on this kind of approach.  If Alice is
sending mail to Bob through such a system, and Bob doesn't have a key
yet, then every e-mail Alice sends is likely to send a query to the
keyserver (or your proxy) announcing "i'm looking to send a message to
Bob!"

This metadata leakage seems like a not-great situation for a
privacy-preserving tool.  How do you intend to mitigate it?

         --dkg