adding TOFU/POP to GnuPG

[Hans-Christoph Steiner]

On 03/14/2014 01:25 PM, Werner Koch wrote:
> On Fri, 14 Mar 2014 16:10, hans at guardianproject.info said:
> 
>> * full SSH style TOFU/POP keyring: the process of adding a key to your local
>> keyring marks it as trusted.  signatures also mark keys as trusted
> 
> You can't compare ssh's key management to GnuPG's.  Indeed ssh works the
> way you describe it but ssh also uses the only the bare key without any
> metadata.
> 
> In our Steed paper [1] we looked in how to implement a TOFC (aka TOFU)
> system into OpenPGP and S/MIME.  In Steed we do not want to talk about
> key ids or fingerprints but use only the mail address to identify the
> key.  To evaluate whether a MitM has been mounted we will need to keep a
> list of recent contacts.  That requires closer interaction with the MUAs
> and can't be done by gpg alone.  However, to make things easier GnuPG
> should keep that list of contacts.


I think that STEED definitely represents an improvement and has a solid ideas
in it. Requiring involvement with MUAs makes it a lot harder to get adoption.


>> * or a more GnuPG style: adding a key to the local keyring adds some trust,
>> but not as much as a signature.
> 
> Not a good idea because the keyring has always been used as white pages
> or as a cache for the keyservers.  Redefining it to gpg's known_hosts is
> not a good idea at all.

I propose using this trust model for people starting new, or for people
willing to switch to it.  It would not be compatible with standard OpenPGP habits.


> Further the notion of different trust levels is hard to define and to
> explain.  For that reason we basically use only 3 levels:
> 
>   - Bad
>   - Might be good but needs manual inspection due to expiration,
>     revocation, no computed trust.
>   - Good
> 
> GPGME uses flags named red, yellow, and green for tehse levels and some
> MUAs put a such colored frame around the message.  

That makes sense.  This is what OTR clients generally do, and it seems
workable.  But I think most OTR users are always chatting in "might be good"
mode.  So "might be good" mode might be not all that useful.  I think
expiration for email is not that useful. Just revokation should handle that all.


> With Steed a mail would be rendered yellow on the very first (few)
> contact(s) and latter either green or red.  In case a key has been
> superseded due to a lost passphrase, the mail would be rendered red but
> a list of previous contacts will be displayed to help the user to
> evaluate what might have happened.  Unfortunately certain circumstances
> delayed the development of a prototype but there is still a lot of
> interest in such a system.
>
>
>> does provide a benefit.  It also does not prevent users from doing
>> stricter verification at any time.
> 
> Users won't do that.

I agree, a good system should not rely on it, but it should provide the
opportunity for the at-risk users who will actually do that.  We work with a
lot of people who actually verify PGP and OTR fingerprints, and we are
involved in trainings to teach at-risk people how to do that.


>> OpenPGP is so over-complicated, and seemingly only getting more so.  And that
> 
> Compared to CMS OpenPGP is a quite lean and stable protocol.  Changes to
> the protocol are very rare: We only have a few RFCs adding new cipher or
> public key algorithms.

Oh yes, there are definitely far worse culprits.  X.509/TLS comes to mind as well.

> The thing is that OpenPGP provides a lot of _optional features_ which
> can be used to model any kind of PKI.  Most of them are not in real use
> and for GnuPG I try to limit the options presented to users.  Still
> there are too many of them and I agree that the interaction of the user
> with the software should be limited to the bare needs.  We experts can
> still to play or use with almost everything from the standard and even
> exchange encrypted messages with all users.

I view GnuPG has a toolbox of trusted crypto components. That is why I think
it is a good system to base such a system on

.hc


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