[messaging] Verified key transitions (was: TOFU to ease PGP key discovery)

[elijah]

On 02/10/2015 10:36 PM, Trevor Perrin wrote:

> On Mon, Feb 9, 2015 at 5:13 PM, elijah <elijah at riseup.net> wrote:
>>
>> (3) We need common practices for "verified key transitions".
> 
> Do you mean this:
>  - When you replace your long-term key, the old key signs the new (and
> maybe vice versa)?
>  - When someone presents their new key with correct signatures, you
> silently replace the old one in your local trust store (no key change
> warning)

Yes. We asked dkg what it should be called, although he may have
intended it to denote only the first part.

> It avoids the warning in (2), but adds complexity - a public key no
> longer matches one fingerprint, now it can be verified by any
> fingerprint that chains to it.  So your protocols have to deal with
> these chains, and users will encounter situations where they had one
> fingerprint for Alice before talking to her, and a different one
> after.

I think we have established that keys will change, regardless of our
desires. Any "automatic" key manager will need to deal with changing
keys anyway. Am I missing something?

One complexity is that the new key, when using OpenPGP, might have many
uids. In this case, any uids not in the intersection of the uids in the
old key and the uids in the new key would need to be stripped from the
new key before accepting it.

> (3) arguably becomes worse, because someone who steals your private
> key can silently replace the public key your correspondents have for
> you, just by messaging them.
> 
> I'm not sure this is a net positive.

We added verified key transitions to
https://pad.riseup.net/p/key-validation for two specific reasons:

(a) For sensitive situations, it should always be recommended practice
to perform manual verification of keys via fingerprint or SAS. Once you
have done this, however, it does not make sense to ever accept a new
public key for that uid without a verified key transition or a new
fingerprint check. To do otherwise would be to defeat the benefit of
checking fingerprints. In our terminology, manual fingerprint
verification is the highest level of validation, and new keys much match
this level of validation or include a verified key transition.

(b) None of the OpenPGP keys in existence currently use any system of
automatic key validation. If you want to send mail to them, an automatic
key manager will need to perform some sort of TOFU (via keyservers,
attached public key, message signature, or header, etc). Once this
happens, the key manager will still need to regularly search for updates
for that key or for that email address. If the key manager does detect a
new key for a uid there will probably still be no automated key
validation support for it. The key manager is then faced with a choice:
blindly accept the new key, require a verified key transition, or
complain to the user. Blindly accepting is not always bad, such as when
you can validate the key via some third party service or protocol, but
in the case of a key that has been purely TOFU'ed, and nothing else,
blind acceptance of a new key would be disastrous. It is very tempting
to say we should prompt the user (in a way, like TLS certificates in the
browser, that nudge the user to say "no"), but I worry this could open
an annoyance attack vector where an attacker can trigger frequent
warnings by polluting keyservers or sending bogus emails to the target.
I think asking would be OK if new key comes inline the message and the
"from" header is DKIM signed.

But yes, automatic "verified key transitions" perhaps make it worse when
private keys are stolen. But maybe it is like rain on a car crash. The
crash is what really sucks, the rain just adds insult to injury.

-elijah