adding TOFU/POP to GnuPG

Hans-Christoph Steiner hans at guardianproject.info
Fri Mar 14 18:11:18 CET 2014



On 03/14/2014 12:25 PM, Robert J. Hansen 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).
> 
> Googling for "TOFU/POP" doesn't turn up anything in the first two pages of
> Google results that isn't associated with you.  My initial reaction is, "until
> it becomes more widely known, let's not do this -- GnuPG is a place for
> established technologies, not a place technologies go to become established."

The term TOFU/POP is not widely used, but that does not mean that the concept
is not widely used or deployed.  SSH has used this model since the 90s, and
SSH has good track record of security.  I've never heard another term for
describing how SSH verifies host keys, perhaps there is a better one.


>> * 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
> 
> You've just made signatures effectively meaningless.  The only way a signature
> can have meaning is if it's on a certificate that for whatever reason isn't
> part of your local keyring.

Yup, that would be one effect of this model, to make it so that signatures on
keys don't change the level of trust of keys in the keyring.  Signatures could
still be used to decide whether to include a key in your keyring.  The big
benefit here is that it is very simple to represent and use.  In my
experience, most OpenPGP users do not ever sign other keys anyhow, and
managing trust settings is even more rare.


>> * or a more GnuPG style: adding a key to the local keyring adds some trust,
>> but not as much as a signature.
> 
> You're just redefining what "untrusted" means.
> 
>> While this does not provide as strong a verification as an OpenPGP signature
>> on a key, it is also much more likely to actually happen, and does provide a
>> benefit.
> 
> What benefit?  It offers nothing that "trust-model always" doesn't.  If you
> want to always trust certificates in your keyring, then set your gpg.conf
> accordingly.

One key difference would be assuming one key per email address.  SSH assumes
one host key per hostname (FQDN).  That is how SSH can judge whether to prompt
you with "unknown key, trust it?" versus "this key does not match this host".

This kind of like "trust-model always", but its subtly different. It would
have to be represented differently to the user to make sense.  For example,
the key import process should not just blindly import new keys.  Instead, it
should walk the user thru the process, i.e. "do you want to trust this key for
this email address?"

.hc

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



More information about the Gnupg-devel mailing list