adding TOFU/POP to GnuPG

[Daniel Kahn Gillmor]

Hi Hans--

On 03/14/2014 11:10 AM, Hans-Christoph Steiner wrote:

> One simple idea has proven quite useful in improving security in other
> protocols, but remains unimplemented in OpenPGP/GnuPG (as far as I know):
> Trust On First Use/Persistence of Pseudonym (TOFU/POP).

I have a TOFU/POP workflow already that works with GnuPG, but it's a
very clunky one, and the tool itself could facilitate this kind of
workflow.  i agree with your general goal here, thanks for pushing this.

> TOFU/POP is how the
> vast majority of people validate ssh host keys.  The idea is to mark a key
> with some degree of trust on the first use (in ssh, its full trust).  Then
> that creates a pseudonym for the service in question (i.e. the ssh server you
> ssh'ed to) which is persisted forever.

It's critically important that we clearly distinguish "trust" from "key
validity".  In no way should any TOFU/POP workflow encourage the
automated setting of trust on any OpenPGP certificate.  The acronym
"TOFU" is misleading in this context.  we're not delegating certifying
authority to a given key; we're granting it some flavor of temporary
validity based on its persistence.

it's also worth distinguishing between keys themselves and certificates
(keys + user IDs + signatures that bind them to each other).  Note that
the thing we care about is some sort of smoother workflow to help users
track key+userID validity -- not key validity or full certificate
validity (because some certs have multiple User IDs and we may only have
evidence of persistent use of some of the associated User IDs).

I'm pretty sure you know this, and didn't mean to suggest automated
setting of trust or key validity without User ID validity, so i'm going
to re-state your proposal points using clearer terminology , and then
see where we can go from there.  Sorry for the pedantry, but i think
it's critical that we get the concepts right before we can figure out
what the right proposals are to make things work:

> * full SSH style TOFU/POP keyring: the process of adding a key to your local
> keyring marks it as trusted.  signatures also mark keys as trusted

this would be: "the process of adding an OpenPGP certificate to your
local keyring makes all user IDs on the certificate automatically valid"

> * or a more GnuPG style: adding a key to the local keyring adds some trust,
> but not as much as a signature.

I think this would be "having an OpenPGP certificate in your local
keyring sets all user IDs in that certificate at marginal validity as a
baseline"

I'm not comfortable with either approach.  mere inclusion in the local
keyring is insufficient for increased User ID validity for several
reasons, not least of which is pretty scary interaction with keyring
maintenance.

 * keyring refresh from keyservers is critical to check for revocations
and subkey rollover -- this is routine maintenance
 * keyring refresh currently allows arbitrary updates by the keyholder,
including addition of new User IDs to existing keys
 * therefore, routine maintenance would allow injection of arbitrary new
User IDs which would be considered valid under this scheme.


GPG has an unusual role in the OpenPGP ecosystem: it's both a message
encrypter/decrypter/signer/validator *and* a keyring/contact/identity
manager.

It's the role as a keyring/contact/identity manager that we want to
flesh out here.  I think to do this right, gpg would need to maintain
some extra internal state about every <key+userID> combination, and use
that state to assign validity to that combination based on TOFU/POP
principles.

Here's a rough sketch of a simple mechanism, not intended as a final
draft, just something concrete for dissection and analysis:

 * let's call each <key+userID> combination a "Contact" -- note that
some keys will belong to multiple Contacts (keys with multiple user
IDs), and some user IDs will also belong to multiple Contacts (e.g.
users with more than one active key with the same UserID on each key,
like those undergoing a key transition).

 * GnuPG could hold a "persistence" state for each Contact, consisting
of a last-seen timestamp T.  This state would be private to the keyring
and never published or exported.  When a key is newly imported, all
Contacts on the key would be set to <T=NULL>

 * GnuPG would have a tunable persistence decay parameter D, which
describes seconds until discard.

 * GnuPG needs to be able to receive a signal from the user (presumably
sent via an application) that a given Contact has been observed (meaning
that the key has been seen in use by the associated User ID).  When this
happens, GnuPG updates <T=now> for this Contact.

 * when GnuPG is asked about the validity of the Contact, it first
checks its usual signature chain validity mechanism; if that validity is
less than "marginal", it returns "none" if (now-T) ≥ D, or "marginal" if
(now-T) < D.

So, for example, enigmail or other MUAs could take advantage of this
mechanism the following way: it would do what it normally does in all
the current cases, but it would make two changes in its handling of a
message that has a body correctly signed by key K and a From: address U,
and it knows of a <K+U> Contact:

 * if the validity of <K+U> is already marginal or better, it should
signal gnupg that the contact has been observed.  (this is the
"persistence of presence")

 * if the validty of <K+U> is none, then the MUA can display an extra
button offering to "accept this contact" (this wording needs help!).  if
the user clicks the button, enigmail should signal GnuPG that the
contact has been observed.

Additionally, when the user *sends* a message to a given Contact and
encrypts it to that contacts key, enigmail might want to signal GnuPG
that this Contact has been observed.


Open questions
--------------

 A) accepting extras vs. ruling out others?

   TOFU is normally used to rule out or explicitly reject other keys for
the same remote peer.  but there are legitimate cases where there are
two Contacts for a given User ID.  should this mechanism refuse to work
(e.g. "you already know the key for user ID U, and this isn't it") if it
sees a new key for that user?


 B) persistence synchronization across devices?

   If the user maintains multiple devices, how should the set of
persistence data be stored across devices?


 C) representing frequency of observation

   the described scheme above is simple (which is good) but it doesn't
have a way to distinguish between a situation where you've exchanged 35
e-mails with a given user, and where you've just gotten an e-mail from
someone who you've never talked with before.  the only distinction is
time of last observation.  a more complex scheme could in some way
account for activity, and base the thresholds or decay based on that
activity (see the TACK mechanism for "learning" a pin for a similar idea).

What do you think about the above?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140314/929d3532/attachment-0001.sig>