TOFU code available

[Neal H. Walfield]

At Fri, 02 Oct 2015 12:12:13 +0200,
Werner Koch wrote:
> On Thu,  1 Oct 2015 23:17, neal at walfield.org said:
> > The main missing bit is the mechanism to normalize email addresses.
> > Currently, I simply ASCII lower-case the local part.  However, I want
> > to use the locale independent case folding data [1] and specially
> 
> I don't think that this is a good idea.  There are no fixed rules and
> the scheme is quite complicated.  We have seen to many problem with that
> in the past and they won't go away.  Further, it is only common use to
> not distinguish case in mail addresses.  The RFCs tell us that only
> "Postmaster" mus be recognized case-insensitive.  But agreed, most users
> don't know about this and thus almost all MTA ignore the case of the
> local part.
> 
> It is good to lowercase ASCII characters because that is well defined
> iff "C" is assumed as locale.
> 
> If people want to use non-ascii mail addresses we better don't try to be
> too smart and take them verbatim.

TOFU can do two things:

  - Identify previously unseen keys, and

  - Detect key changes.

We don't implement the first thing by default (although it can be
enabled by setting --tofu-default-policy=ask).  This policy decision
is based on the observation that if we have too many user
interactions, the user will simply dismiss all questions without
actually understanding them thereby undermining any security
improvements that TOFU brings.

The second thing detects man-in-the-middle attacks.  It requires
binding keys to identifiers and detecting when that identifier is
associated with another key.  I argued in a previous mail that the
right identifier is an email address and there seems to be rough
consensus that this is the best approach.

If we are conservative in what we consider to be equivalent email
addresses, then we make it easy for an attacker to circumvent this
protection.  If we are liberal, we run the risk of incorrectly
flagging conflicts when there are none (i.e., introducing false
positives).

I suspect that in practice false positives will be extremely rare.
Permitting false negatives, however, can have dire consequences (and
if you don't consider them dire then you probably don't care about
TOFU).  Therefore, I strongly argue that we should aggressively
normalize email addresses before comparing them.

Consider the attack that we are trying to protect against: Eve wants
to send an email to Alice that appears to come from Étienne.  Eve
assumes that Alice and Étienne are in regular contact and that
Étienne's key is: <0xdeadbeef, étienne at example.org>.  Eve also knows
that Alice uses GnuPG with its TOFU trust model and that GnuPG's
--auto-key-locate functionality is enabled.  To mount the attack, Eve
needs to create a key that will be acceptable to TOFU without raising
a conflict.

If we choose a conservative comparison function, this is trivial.  Eve
creates a new key <0xbaddecaf, Étienne at example.org> and signs a
message that she sends to Alice using this key.  Although Alice has
never seen this key, she doesn't realize it: GnuPG silently fetches
the key for her.  Further, because Alice is using TOFU in its default
configuration, the binding is considered to be new and hence fully
trusted.  Now, it's up to Alice.  This is what she sees:

  gpg: Signature made Mon 05 Oct 2015 08:53:36 PM CEST
  gpg:                using RSA key 0xbaddecaf
  gpg: Good signature from "Étienne <Étienne at example.org>" [full]

For Alice to win, she needs to recognize that either the key id or the
email address has changed.  Most people won't recognize changes to the
key id.  And, given how optically similar the email addresses are,
Alice is unlikely to recognize the difference there as well.  As such,
Eve almost certainly wins.

For Eve to lose, we must force her to choose an email address that
Alice detects as being wrong.  For instance, if we force Eve to choose
foo at example.org, then Alice has a good chance of noticing the
suspicious email address.  Such an extreme choice is not possible, but
we can make Eve's life more difficult by lower-casing all letters,
removing accents, removing punctuation, etc. before comparison.

> > handle gmail addresses (e.g., dots are simply ignored).  If you are
> > aware of existing code that would help me do either of these things,
> 
> At our meeting on Wednesday we discussed this and my point was that if
> we do this, we should do it in the same way Google handles addresses
> in their forthcoming OpenPGP service.

Note: the point is not to come up with the canonical email address,
but to compare two email addresses and indicate whether they are
similar enough that a warning is justified.

Thoughts?

Neal