Are TOFU statistics used for validity or conflict resolution?

[Teemu Likonen]

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"
>> mode?
>
> 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:


       --trust-model pgp|classic|tofu|tofu+pgp|direct|always|auto

              [...]

              tofu

                     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
                     man-in-the-middle attack.


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...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20170623/02886567/attachment-0001.sig>