adding TOFU/POP to GnuPG

[Hans-Christoph Steiner]

On 03/14/2014 01:00 PM, Daniel Kahn Gillmor wrote:
> 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


My goal in bringing up TOFU/POP is to simplify things, OpenPGP is already way
over-complicated so adding more fine grained control over new aspects would
only make things worse for the large majority.  The goal is to make a small
subset of OpenPGP that is usable by anyone who uses email.  Simplicity also
makes security analysis a lot easier.

Yes, this would reduce the flexibility but OpenPGP is far too complicated for
the vast majority of users to understand.  Its taken me years of using it to
feel I have some grasp, and I still feel lost it in.  So I'm talking about a
mode that is designed for anyone who can use email.  I am not talking about
changing the existing, standard OpenPGP model, so those who want all that
complexity and flexibility can choose that route.

Key to this idea is that the user would always manually approve all additions
and changes to keyId+email mappings in their local keyring.  That's the very
basis of TOFU/POP.  Ideally there would only be one key per email address, but
workaround should be possible for people who insist on multiples, for the sake
of compatibility.  But I think the interface should strongly encourage a
one-to-one mapping of key<-->email.

In the pure TOFU/POP model, keyservers would only used for updates about
revokation, expiry, and subkeys.

As for my language, sorry I don't speak proper OpenPGP/IETF speak.  I've tried
to learn it, but it has so many arcane details that it does not stick in my
brain.  So I'll stick to standard English and try to make myself understood.

.hc



-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

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