Handling a TOFU conflict

[Neal H. Walfield]

On Thu, 08 Dec 2016 21:09:44 +0100,
Andre Heinecke wrote:
> On Thursday 08 December 2016 20:41:43 Neal H. Walfield wrote:
> > I find it hard to imagine that detecting homographic-based conflicts
> > would introduce many false positives.
> 
> My goal is to detect / resolve problems on the senders side. Using a new mail 
> address that is "homographic" different is not an attack to me. Please outline 
> how a homographic conflict could be used as an attack on TOFU. Please do not 
> see this as unconstructive bashing. I am currently in the process of trying to 
> create / understand an attack tree on a TOFU trust model, and I just don't see 
> homographic attacks there.

A homographic attack is not an attack on TOFU; it is an attack on the
user.  TOFU can help prevent such attacks.

Let's say, Alice and Bob communicate with each other regularly, and
that an attacker wants to trick Alice into sharing some of her secrets
with Bob.  The attacker could send her an encrypted and signed email
from "B0b" with the body, "Can you please send me document so and so."
If TOFU detects this, it can warn Alice about the potential phishing
attack.  If not, Alice needs to recognize that the mail was from B0b
and not Bob, which is not easy even if Alice is a sophisticated user.
The TOFU statistics help Alice detect this type of attack.  But, if we
are able to detect obvious homograph attacks and instead raise a
conflict, that would, IMO, be better.

> > > > > Then we'll have to disagree.  I would honestly and sincerely like to
> > > > > hear what you think TOFU is trying to protect against.
> > > > 
> > > > To detect and warn about a different key with the same mail address.
> > > 
> > > I'm also in agreement, I think TOFU is most important as a tool for
> > > automated encryption. And as long as I won't try to write mails to
> > > "T0FU at example.com" instead of "TOFU at example.com" this is a non issue.
> > 
> > Serious question: what is this tool (i.e., TOFU) supposed to do?  That
> > is, how is it supposed to help automated encryption?
> 
> It should help in two cases:
> 
> a) You have some weak indication that the sender is who he claims because you 
> have communication history with him.
> 
> So after some history you can show an indicator "Ok this is really who you 
> think that is belonging to the senders address"

I agree that we want to use TOFU to provide weak authentication (i.e.,
verify that entity X controls key Y).

> b) You can be confident that the recipient can decrypt your messages because 
> you have history that he used the key for signing messages to you. Or 
> alternatively you think that he was able to decrypt messages sent to him.

This isn't a trust model's goal (a trust model is about verification).
But clearly, any key that is verified will satisfy these requirements.

The difficult question is: how to we find an appropriate key for a
given entity when we haven't verified the entity?  It is appealing to
use TOFU, whose judgments are based on history, but this is a hack.
Instead, we should provide a separate interface that answers the
question: "If I want to send a message to bob at example.com what is the
best key?"  How exactly this works is an implementation detail, but it
could internally reuse some of the facts that the TOFU engine has
collected.

Thanks,

Neal