Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

[Duane Whitty]

On 17-06-05 11:11 PM, Daniel Kahn Gillmor wrote:
> On Tue 2017-06-06 01:24:43 +0200, Stefan Claas wrote:
>> On 05.06.17 22:26, Daniel Kahn Gillmor wrote:
>>> what does "bullet-proof" mean, specifically? 
>>
>> For me it means that the idendicons should be visually easy to read
>> and cryptographically secure. Sorry that i have no better explanation.
> 
> here's one way to try to frame the question: Imagine the situation as a
> game, where you have two players on one team, "defense" named Alice and
> Bob; Alice wants to send a message to Bob.  Another player on the
> opposing team, "offense", is named Mallory, is trying to send a message
> to Bob as well, but trying to trick Bob into thinking that the incoming
> message comes from Alice.
> 
> The way the game is played, either Alice or Mallory gets to send a
> message.  Bob has to decide whether the message actually came from
> Alice.  If Bob gets it right, the "defense" wins.  If Bob gets it wrong,
> the "offense" wins.  The game is played multiple times.
> 
> Is that the scenario you're thinking of?  If so, does the defense need
> to win 100% of the time over thousands of games?  or is it acceptable
> for offense to win occasionally?
> 
> In any case question is: how much work does Mallory need to do to get
> Bob to make a mistake?  How frequently can Mallory trick Bob into
> accepting mail from her as though it were from Alice?  Conversely, how
> many messages that were actually from Alice can Bob accidentally reject
> without making Alice upset enough to give up on the entire
> communications scheme?
> 
> When you frame the problem this way, you can start thinking more
> concretely about what "bulletproof" means, and you can actually design
> user trials to test proposals.
> 
> There are probably other ways to concretize the problem, this is just
> one that i've come up with.  But without a concrete way to understand
> what we're looking for, words like "bullet proof" or "easy to read" or
> "cryptographically secure" are tough to get people to agree on.
> 
> I suspect (as discussed upthread) that TOFU will have better metrics for
> "defense" at the game described above than any attempt that involves
> asking people to visually distinguish deterministically-generated
> identicons.  But i don't know, because i haven't tested it.
> 
>                    --dkg
> 

Excellent scenario and explanation Daniel, thank you!  I firmly believe
your suspicions regarding identicons will be fully shown accurate.

However, I am having difficulty following how TOFU would/could provide
better metrics for the "defense" side of the game.  As I understand the
concept of TOFU (Trust On First Use), when you receive a signed email
gpg tests that signature against the key retrieved from the public key
servers associated with the email.

To me this says nothing about whether you are actually communicating
with who you think you are communicating with.  It justs says "Yes, the
signature on the email you received was generated by the same key
associated with that email address on the public key servers."

This is not enough to convince me I am communicating with someone I
know.  For instance, I have not imported even one of the many keys I
receive from emails to this mailing list into my keyring because there
is no trust there.  And when I move to gpg 2.1 I will make certain that
TOFU is not enabled.

I think TOFU could potentially be a win for Mallory.  TOFU may make
people more likely to take for granted that they are communicating with
a trusted party because the email they received says it's someone they
trust and GPG says it's a good signature from alice at example.com.

The problem with this is that they never communicated with Alice to
learn her email address is actually alice at trustme.com.

My personal opinion, for whatever that is worth, is that TOFU is going
to have people sending signed/encrypted email back and forth to each
other without them having done the work to ensure they are actually
communicating with their intended parties.  Trust takes work.

Once the work on establishing identities has been done and trust has
been established there is no need to remember keys because the key will
be locally associated with the email address belonging to the trusted
party you wish to communicate with.

Best Regards,
Duane

-- 
Duane Whitty
duane at nofroth.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170606/763a9db8/attachment.sig>