adding TOFU/POP to GnuPG

[Hans-Christoph Steiner]

On 03/14/2014 03:07 PM, Daniel Kahn Gillmor wrote:
> On 03/14/2014 02:00 PM, Hans-Christoph Steiner wrote:
> 
>> My goal in bringing up TOFU/POP is to simplify things, OpenPGP is already way
>> over-complicated so adding more fine grained control over new aspects would
>> only make things worse for the large majority.  The goal is to make a small
>> subset of OpenPGP that is usable by anyone who uses email.  Simplicity also
>> makes security analysis a lot easier.
> 
> You may not want OpenPGP for this, then.  OpenPGP clients have to cope
> with data that they see that covers the whole spec, even if they want to
> present a simplified interface for users.
> 
> But if you want interoperability with the installed set of OpenPGP
> users, as small as that group  may be, this is the standard to use.

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.


>> Yes, this would reduce the flexibility but OpenPGP is far too complicated for
>> the vast majority of users to understand.  Its taken me years of using it to
>> feel I have some grasp, and I still feel lost it in.  So I'm talking about a
>> mode that is designed for anyone who can use email.  I am not talking about
>> changing the existing, standard OpenPGP model, so those who want all that
>> complexity and flexibility can choose that route.
> 
> you'll note that the only user-facing parts of my proposal were a single
> button added to the MUA, and a possible configurable knob for GnuPG
> itself (the decay parameter D, which we can presumably choose a
> reasonable default for so users won't see it).
> 
> I'm with you on not exposing extra complexity to the users; there is
> already too much exposed.

I also worry that complicated systems can also be gamed more easily without
people noticing.


>> Key to this idea is that the user would always manually approve all additions
>> and changes to keyId+email mappings in their local keyring.  That's the very
>> basis of TOFU/POP.  Ideally there would only be one key per email address, but
>> workaround should be possible for people who insist on multiples, for the sake
>> of compatibility.  But I think the interface should strongly encourage a
>> one-to-one mapping of key<-->email.
> 
> This also seems quite possible, within the constraints i mentioned
> above.  you'd want to modify the decision about when to present the
> button to the user, probably.
> 
>> In the pure TOFU/POP model, keyservers would only used for updates about
>> revokation, expiry, and subkeys.
> 
> how does new key discovery work if keyservers are not used in this
> context?  what about new User ID discovery on existing keys?

Yeah, keyservers would be used for getting new keys too.  Getting new IDs from
keyservers would be fine too, as long as the interface asks the user to accept
the new key+ID mapping.  Having key signatures on the keyservers should be
optional, not default.

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.


>> As for my language, sorry I don't speak proper OpenPGP/IETF speak.  I've tried
>> to learn it, but it has so many arcane details that it does not stick in my
>> brain.  So I'll stick to standard English and try to make myself understood.
> 
> Unfortunately, there is no standard English for some of these concepts,
> and in other cases, the standard English refers to multiple things that
> we need to distinguish between as implementers.   so it's critical to
> use unambiguous terminology if we want to nail down what we're actually
> hoping to do.  Please try.
> 
> "trust" in the OpenPGP world (and in the X.509 world) is an indication
> that the user is willing to rely on certifications made by the key in
> question.  "validity" is whether the key and the user ID should go
> together.  "this key+UserID is valid" is the same as "we should expect
> the person identified by this User ID to use this key".
> 
> 	--dkg

If we are implementing trust models that we cannot explain in plain English,
how then do you expect to represent them to users who have no idea about the
implementations?

.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/82fc6b7a/attachment-0001.sig>