Handling a TOFU conflict

[Neal H. Walfield]

Hi,

On Wed, 07 Dec 2016 21:02:03 +0100,
Werner Koch wrote:
> On Wed,  7 Dec 2016 11:40, neal at walfield.org said:
> 
> > Sorry, the --command-fd option is just a distraction.  But, it is how
> > epg currently works, AFAICT.
> 
> Not really because it is the reason for the "GET_LINE tofu.conflict"
> which we can't use with any GPGME enabled MUA.  Insofar epg diverts from
> GPGME's behaviour.

If I remove the --command-fd, then I still get the "GET_LINE
tofu.conflict".  Only if I add --batch is it disabled.

It seems that epg is not using --batch and is using --command-fd.  So,
it does indeed diverge from gpgme.

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.

> > You only see the TOFU_STATS lines for the keys under consideration.
> > It would be nice to have a way to immediately get the statistics for
> > the conflicting keys.  That is what this patch is about.
> 
> You need to do a key listing anywa to get all details of the key.  Thus 
> 
>  gpg --with-colons --with-tofu-info MAILADDRESS
>
> while give you all information you need in a format you already need for
> displaying the details of the key.
> 
> Adding a hint on which key conflicts might be useful but is not necessary.

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.

> > 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
> 
> For Tofu and all kind of "modern" key discovery, we soley use the mail
> address - that is the unique identifier and not some garbage in the user
> id.
>
> > that we use.  Currently, we only lowercase the email address, but one
> > could imagine adding support for google's aliases ('.'s don't mean
> 
> Definitely not.  As soon as you start to special case things you are
> violating implicit assumptions and will for sure run into problems.
> Downcasing _ascii_ in contrast is different because case independent
> matching is a >30 old practice and not doing this would be a surprise.

I don't understand what your concerns are.  This is about how TOFU
internally detects conflicts; what implicit assumptions are there
about how this is supposed to work?  Why should the TOFU
implementation not try to detect homograph attacks?

> > I'm sorry, I don't understand why specifying a key by fingerprint
> > should cause that key to be fully trusted.
> 
> Because the the user said: “Please encrypt to exactly this key”.  And
> that is what gpg does - questioning this request is wrong.  This may
> only fail when the key may not be used for other reasons (revoked,
> expired, wrong capabilities).
> 
> > Can you please elaborate.  I have a rather different understanding of
> > what TOFU is about.  (If you are interested: it's about monitoring
> > bindings for conflicts.)
> 
> If a users demands _encryption_ to a certain well specified key (ie. by
> fingerprint of with -f) gpg shall just do that.  The story is different
> when receiving mail: Verification shall of course detect conflicts.

I just tried this using the WoT and gpg doesn't handle this case
specially:

  $ gpg --trust-model pgp -e -r 0xEE7C7DA4BE04EB2B -a
  gpg: 0x73C970E81D63F2D5: There is no assurance this key belongs to the named user
  sub  rsa2048/0x73C970E81D63F2D5 2016-12-05 Joke Factory <joke.factory at example.com>
   Primary key fingerprint: 97D6 8CB9 B03F 8137 EB88  4940 EE7C 7DA4 BE04 EB2B
        Subkey fingerprint: C22F 9255 B78B 42DE 9BD0  8E37 73C9 70E8 1D63 F2D5
  
  It is NOT certain that the key belongs to the person named
  in the user ID.  If you *really* know what you are doing,
  you may answer the next question with yes.
  
  Use this key anyway? (y/N) 

So, it seems to me that what gpg currently does is wrong.  Or, I'm
misunderstanding something.  Can you please elaborate?

Thanks!

:) Neal