Handling a TOFU conflict

[Neal H. Walfield]

On Thu, 08 Dec 2016 00:06:26 +0100,
Werner Koch wrote:
> On Wed,  7 Dec 2016 22:32, neal at walfield.org said:
> > As far as I can tell, whether the client uses the "GET_LINE
> > tofu.conflict" or not, whether to supply the list of conflicting keys
> > is orthogonal.
> 
> Yep.  But that is not how GPGME works, which is my primary concern.
> If EasyPG wants to handle this different, so be it - but changing
> our interface for this is a no-go.

So, your primary convern is that EPG is using --command-fd while gpgme
is using --batch.  I think this is reasonable.  Daiki will need to
decide how he wants to handle this, but I suspect it is a fair amount
of destabilizing work and won't make it into the next version of
Debian.

> Adding additional status information in
> case of conflicting keys is acceptable as long as we have this info
> already available.  In fact we already have all status lines for this
> available:
> 
>   TOFU_USER <fingerprint1> <mbox>  
>   TOFU_STATS 0 ....
>   TOFU_USER <fingerprint2> <mbox>  
>   TOFU_STATS 0 ....
> 
> indicates that the two keys FINGERPRINT1 and FINGERPRINT2 conflict on
> the address MBOX.  (The 0 is "conflict" value of that SUMMARY byte).

My experiments suggest that this information is not available (see
Message-ID: <87wpfd175i.wl-neal at walfield.org>).  My proposed patch
in that mail changes this.

> > Well, as far as I can tell, the TFS records and the TOFU_STATS contain
> > the same information.  Your approach also doesn't exclude keys that
> > are known now to conflict with the selected key (e.g., if they are
> > cross signed), and doesn't deal with the aliasing issue.
> 
> I have noticed that you put code in place to detect this and thus avoid
> a conflict.  What do you mean by aliasing?

Say we have a at example.org and a at example.org (the first a is a latin a
and the second a is a Cyrillic a) and we internally normalize them to
be the same thing (i.e., we decide that a at example.org and
a at example.org conflict even though a memcmp says they are not
identical), then doing gpg -k mbox won't find all of the conflicts,
because gpg doesn't do the same transformation.

> > about how this is supposed to work?  Why should the TOFU
> > implementation not try to detect homograph attacks?
> 
> Because that is not the duty of gpg - this is an entire different layer.
> A MUA _might_ care about this but most likely it can only support the
> user in detecting this.  This has nothing to do with with T0FU.
> 
> Mixing up layers is the cause of a lot of evil.

TOFU is about monitoring bindings to detect conflicts.  If we don't
try to actively detect conflicts, then we are left with
--always-trust.  Thus, this is precisely the type of thing that TOFU
is trying to do.

If you think TOFU is about something else, I'd like to hear your
definition.

> > I just tried this using the WoT and gpg doesn't handle this case
> > specially:
> 
> Right, but with T0FU we are going to improve this.  Before 2.1.16 we did
> not distinguish on how a key was specified.  Now a key specified by mail
> address is treated different than a key specified by other means.  This
> is to support our major goal of easily using the right key for a mail.
> With tofu and tofu+gpg we can and should drop the old checks and
> consider a key specified by fingerprint as DWIW-and-encrypt-to-this-key.
> For backward compatibility we can't do this for the pgp trust model.
> 
> Thus it will eventually be possible for MUAs to avoid the use of
> GPGME_ENCRYPT_ALWAYS_TRUST (--always-trust in gpg) after the keys have
> been selected and passed by fingerprint to gpg.

I missed this discussion.  Thanks for clarifying.  I need to think
about whether this is a good idea or not.

:) Neal