Handling a TOFU conflict

[Neal H. Walfield]

On Wed, 07 Dec 2016 11:27:09 +0100,
Andre Heinecke wrote:
> On Tuesday 06 December 2016 15:09:13 Neal H. Walfield wrote:
> > Currently, when a TOFU conflict is encountered, the --status-fd
> > transcript looks like the following:
> 
>  ...
> 
> > 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 don't think this is a problem, gpgme exposes the mail normalsation as API 
> and I don't see a security problem with a race for the additional keylisting.
> Do you have concerns there?
>
> A mua needs the E-Mail normalisation anyway to provide the argument for
> --sender.

The race is minor and it occurs to me that it is unavoidable anyways
so this is a moot point.


The more important issue has to do with listing conflicting keys.
AFAICT, there is no reason for TOFU to necessarily normalize a user id
in a way that the rest of gpg understands.  Consider the case where we
try to protect against homograph attacks by mapping characters with
similar glyphs to the same symbol.  In this case, a "Cyrillic a" and a
"latin a" might be assigned the same symbol, and asking gpg to find
the key corresponding to the normalized email address can result in no
keys being found.

I don't think it makes sense to expose TOFU normalization to the rest
of gpg nevermind to external libraries or applications.  This is
particularly the case if we want to preserve the flexibility to
identify new conflicts in the future, which would require changing the
mapping function.  As such, I think it is necessary for the TOFU code
to emit the list of conflicting keys.

If we are going to emit the conflicting keys, then we might as well
also emit the stats, since the data is readily available.  But, I
don't care too much about this point.

In short: I think it is essential that we emit the set of conflicting
keys when a conflict is encountered.

> > 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
> > 
> > I'm confident that this would at least simplify the TOFU integration
> > in EPG.  Other thoughts?
> 
> I think this complicates things and creates work as we have to add this to 
> GpgME, too and is not neccessary.
> Altough I have no strong objection if you impement this. It would be 
> additional information and it may help others.
> 
> I currently don't think that I need information about an old key at all in 
> case of a conflict in the user interface. But that's a different discussion. :-)

I'm not sure what you mean by an old key.  If there is a conflict,
then you need to show all of the keys, right?