adding TOFU/POP to GnuPG

[Hans-Christoph Steiner]

On 03/14/2014 05:10 PM, Daniel Kahn Gillmor wrote:
> On 03/14/2014 04:28 PM, Hans-Christoph Steiner wrote:
>> Sure, it doesn't need to be OpenPGP.  But GnuPG seemed like a natural place to
>> try this out since all of the pieces are there, and its widely deployed and
>> tested.
> 
> if you don't care about interoperability with the existing OpenPGP
> userbase, i think using OpenPGP gets you stuck in a maze of
> compatibility and complexity concerns.
> 
>> I also worry that complicated systems can also be gamed more easily without
>> people noticing.
> 
> This is definitely true.
> 
>> I think a nice, simple idea to explore here is "secure introductions".
>> Basically, if you send multiple people an encrypted email, you include a
>> signature marking the key+email combos as trusted.  Then if the recipients
>> trust your key+email, their program will automatically import any new
>> key+email combos (i.e. download and mark them as trusted).  The whole public
>> key could be contained in the secure introduction.
> 
> again, I think you're conflating belief in key+userid validity with
> trust here, and that conflation is likely to violate people's
> assumptions and preferences.
> 
> humans are actually pretty good at understanding the difference between
> "do you know who this person is?"  and "is this person someone you can
> rely on?"  -- the difference is significant.
>
> how many hops into such a chain should these "secure introductions"
> propagate automatically?
> 
> The other angle that needs consideration for a TOFU/POP workflow is what
> sort of experience people should have when things fail.  This is the
> achilles heel of TOFU/POP, and despite it coming up rarely in
> experience, it actually matters tremendously to the security of the
> entire scheme.
> 
> What do you think a user should see when a new key appears for one of
> their contacts, for whom they already have a key?  is there a way that
> the user can distinguish between legitimate key rollover and an
> impersonation attack?  What signals do they have to detect and deal with
> the situation that are better than "click OK to get on with your work?"

Humans are very good at making value and trust judgments, computers are
terrible at it even with help from humans.  So we should leave that to humans
to distinguish and not attempt to make computers do it.  Crypto protocols
should focus on the parts that computers are good at, and the software that is
based on those protocols must focus on representing the true state of affairs
as understandable as possible.

What needs exploring are other approaches.  For example, thinking more like a
biologist and basing decisions on lots and lots of observations.  Computers
are good at observing and checking keys, so let's give them lots of
opportunity to do so.  The hard part here is then representing decisions that
the user must make, and guiding them through concrete actions.  That must
happen in any existing, functional crypto system, be it WoT, TOFU/POP, CAs,
whatever.  There are points where the user must make a decision.

Usable crypto systems are not mathematical proofs: there will always be messy
things that the user will have to think about them.  The realistic goal is
minimizing them and making them understandable.

There are lots of details here to be resolved of course, and I don't
personally have time now to really work on them.  I am just happy to spur
discussion here.

As for blenders, I regularly am involved in crypto design processes and work
to avoid jargon. I think it is not only possible, but indeed leads to better
design.  And I think its generally a waste of time to debate metaphors.

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 969 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140314/56795b03/attachment-0001.sig>