Handling a TOFU conflict

Andre Heinecke aheinecke at intevation.de
Thu Dec 8 21:09:44 CET 2016


Hi,

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.

> > > > 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"

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.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161208/68712d71/attachment.sig>


More information about the Gnupg-devel mailing list