Handling a TOFU conflict

[Daniel Kahn Gillmor]

On Tue 2016-12-06 09:09:13 -0500, Neal H. Walfield wrote:
> Currently, when a TOFU conflict is encountered, the --status-fd
> transcript looks like the following:
>
>   $ gpg --command-fd 0 --status-fd 1 --trust-model tofu -r 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 -e 
>   [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
>   [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
>   [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
>   [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
>   The email address "joke.factory at example.com" is associated with 3 keys!
>   Please indicate whether this email address should be associated with key
>   16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 or whether you think someone is
>   impersonating "joke.factory at example.com".
>   
>   This key's user IDs:
>     Joke Factory <joke.factory at example.com> (policy: auto)
>   
>   Statistics for keys with the email address "joke.factory at example.com":
>     1604 5E5F D857 2D7C 44AA  6DCE CC8D 32F3 1C00 5AF3 (this key):
>       Encrypted 0 messages.
>       Verified 0 messages.
>     6F34 3BAD CC2A BE3C 5A2E  295B 2A16 A78F B662 E42F (policy: auto):
>       Encrypted 0 messages.
>       Verified 0 messages.
>     97D6 8CB9 B03F 8137 EB88  4940 EE7C 7DA4 BE04 EB2B (policy: auto):
>       Encrypted 0 messages.
>       Verified 0 messages.
>   
>   Normally, an email address is associated with a single key.  However,
>   people sometimes generate a new key if their key is too old or they think
>   it might be compromised.  Alternatively, a new key may indicate a
>   man-in-the-middle attack!  Before accepting this association, you should
>   talk to or call the person to make sure this new key is legitimate.
>   
>   [GNUPG:] GET_LINE tofu.conflict
>
> The MUA has to manually figure out what the conflicting keys are and
> gather the statistics.  In addition to the extra work for the
> programmer and the minor computational overhead, this introduces a
> small race.  Further, it means that the MUA has to know that conflicts
> are based on the email address (and not whole user id) as well as any
> normalization rules that we use.  Currently, we only lowercase the
> email address, but one could imagine adding support for google's
> aliases ('.'s don't mean anything) and puny code.
>
>
> I think that we should change this to print the stats for each
> conflicting binding before the tofu.conflict prompt is emitted.  For
> this, I propose either using pairs of TOFU_USER/TOFU_STATS lines or
> just using the TOFU_STATS line, but extending it to include the
> required context (i.e., the fingerprint and the mbox).  Thus, the
> --status-fd output could look like this:
>
>   [GNUPG:] KEY_CONSIDERED 16045E5FD8572D7C44AA6DCECC8D32F31C005AF3 0
>   [GNUPG:] TOFU_USER <fingerprint> <mbox>
>   [GNUPG:] TOFU_STATS ...
>   [GNUPG:] TOFU_USER <fingerprint2> <mbox>
>   [GNUPG:] TOFU_STATS ...
>   [GNUPG:] GET_LINE tofu.conflict


given the output you show above, it sounds like GnuPG already has the
information available in order to write the non-status blurb.

I completely agree that we should supply this info on the --status-fd so
that MUAs that want to integrate with this have access to the
information.

I lean in the direction of a single TOFU_STATS line per considered key,
rather than a pair of TOFU_USER+TOFU_STATS -- it's just easier for
clients to parse a single line at a time.

Also, i note that in your example there were three keys, but above you
only show two.  i'd hope that that we'd emit TOFU_STATS for the
currently-considered key as well as for the other known keys that match.

Thanks for thinking this through, Neal!

       --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20161206/7ad1e884/attachment.sig>