Are TOFU statistics used for validity or conflict resolution?
tlikonen at iki.fi
Fri Jun 23 12:45:39 CEST 2017
Neal H. Walfield [2017-06-23 11:14:31+02] wrote:
> At Thu, 22 Jun 2017 20:32:48 +0300, Teemu Likonen wrote:
>> Then let's say I have a key which has been used to verify hundred or
>> so signatures. In --status-fd's TOFU_STATS <summary> it gets higher
>> value, say 4. Then the keyring gets a new key with conflicting email
>> address. Does gpg again set both keys (user ids) to tofu's "ask" mode
>> or does this higher number of good verifications automatically keep
>> the first key in "auto" mode and only the new key is set to "ask"
> No, both keys are set to ask. The key with a lot of observed
> signatures could be bad. This could occur, if there is a MitM, but the
> MitM has a small lapse, because, perhaps, you've used an unintercepted
> network path to retreive the "new" signature & key.
Thanks. So here's how my thinking has been as a tofu newbie.
1. I assumed that the first key with particular email address would be
automatically valid forever. Only new keys would go to "ask" mode on
conflicts. That was my interpretation of "trust of first use". Well,
I was wrong.
2. New hypothesis: There needs to be enough history on verifying or
encryption before the key is assumed automatically valid on
conflicts. Then only new keys would go to "ask" mode on conflicts. I
was wrong again.
I don't know whether my thinking is common but perhaps it would be
helpful if gpg's man page made clear that on conflict situation both
keys go to "ask" mode. A quote from my gpg 2.1.18 manual:
TOFU stands for Trust On First Use. In this trust
model, the first time a key is seen, it is
memorized. If later another key is seen with a user
id with the same email address, a warning is
displayed indicating that there is a conflict and
that the key might be a forgery and an attempt at a
From that part I got the idea of getting warning only from new
conflicting keys. The first one would be trusted. The man page doesn't
say so but it was my interpretation.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the Gnupg-users