TOFU - motivation

[Daniel Kahn Gillmor]

Hi Neal--

Thanks for this thought-provoking suggestion.  I've tried to think this
through more concretely, and written up my thoughts below.  I'm not
prepared to drive this project, but i agree that it could be valuable
for the GnuPG community if it was done right.

On Tue 2015-03-31 14:26:48 -0400, Neal H. Walfield wrote:

> I'm thinking about how to implement trust on first use (TOFU) in
> GnuPG.  In this note, I want to lay the ground work.  This is probably
> uncontroversial, but I think it is important to state it explicitly.
>
> TOFU is good for checking an association between an identity (in our
> case, an email address) and a key.  The idea is the following.  The
> first time that we observe a message from a particular email address,
> we record the email and the key.  After that, each time we receive a
> message, we check that the same key is used.  If not, then we issue a
> warning and the user can decide what to do.
>
> There are a few reasons that the key associated with an email address
> could change.  First, the user may have a new (or another) key.  In
> this case, we want to associate all valid keys with the address.
> Second, there is an active MITM attack.  TOFU can detect this if the
> MITM is not always successful.  Finally, the from line was faked and a
> different key was used to sign the message.  TOFU can also reliably
> detect this.  In all three cases, the user may not realize what
> happened if TOFU is not used.
>
> There are two convincing reasons to implement TOFU in GnuPG and not in
> the user's MUA.  First, we want to preserve the trust database even if
> the user changes MUAs.  This is significantly easier if all MUAs use
> the same infrastructure.  Second, we want to reduce the burden on the
> MUA authors.  If the MUA authors implement all the infrastructure
> themselves, then there will be N implementations.  If GnuPG implements
> it, there will be just one and each MUA will need to interface with
> GnuPG, which is probably significantly easier.

I think this responsibility should be shared between the MUA and GnuPG.

GnuPG manages the keyring, and should therefore record the state of the
TOFU data.  the MUA interfaces with the user and with the user's mail
store, and should know how to tell GnuPG about these TOFU transitions
simply.  The devil is in the details, though.


TOFU about what?
================

We have to be clear what we think TOFU is about: is it related to an
e-mail address or to a User ID?  If it were a full User ID, and you
received mail from "John Smith <john at example.org>" then i could trick
you into accepting a new key for "John Q Smith <john at example.org>" and
your system would be no wiser.  So i think we're talking about a TOFU
mapping from an e-mail addresses to a primary key.  Right?



How to get there
================

If we want to do this effectively, we need to make sure that all users
of GnuPG understand how TOFU-style annotation, insertion, and update
should work.

This is probably work that needs doing at two levels within the GnuPG
project itself:

 0) figure out how TOFU assertions should be stored by GnuPG

 1) figure out if GnuPG should offer any more-convenient interface to
    set and update these assertions (this would facilitate work by
    consumers of the GnuPG interface)




0 seems like the easier job to me, so i'll start there:

Storing e-mail TOFU assertions in the keyring
=============================================

I think the way to store this sort of thing internally would be
non-exportable certifications (possibly issued by a dedicated key)
marked with a particular OpenPGP notation to indicate that they're from
this TOFU approach.

OpenPGP Notations: https://tools.ietf.org/html/rfc4880#section-5.2.3.16

This leaves a few relatively simple questions still unanswered:

 a) what name/value should the notation have?  tofu at gnupg.org seems
    plausible for the name, if werner is ok with it.  I'm not sure what
    we'd need in the value here.  maybe a version of the TOFU scheme,
    just in case there's a revision to this later?

 b) what "cert-level" should this use?  I tend to believe that
    cert-levels are not useful, and are possibly dangerous [0], so i
    recommend using generic certification (0x10).  Alternately, this
    could be one case (maybe the only case) where cert-levels could
    actually find a use: if these TOFU certifications were all done with
    "persona certification" (0x11), and gpg could be configured to
    believe or not believe this level of certification from a given key,
    this could help to keep TOFU certifications out of accidental/normal
    use.

 c) should the notation be marked as critical or not?  I tend to think
    it should be marked as critical to avoid other systems importing or
    relying on these certifications without understanding the nature of
    the TOFU approach.


Additional e-mail TOFU interfaces
=================================

here are some proposed TOFU interfaces that gpg could provide:

Options:

  gpg --email-tofu-issuer $KEYFPR
  gpg --no-email-tofu

These options would turn on (or off) TOFU support, using $KEYFPR as the issuer of
all internal TOFU signatures.


Commands:

  gpg --email-tofu-seen $EMAIL $KEYFPR

If gpg already thinks that $KEYFPR is valid for a user ID that maps to
$EMAIL, then this returns 0 ("everything is OK") and terminates.

If --no-email-tofu is set, this returns 1 ("email tofu not configured")
and terminates.

If there is some other key that is valid for any User ID that maps to
$EMAIL, this returns 1 ("unable to associate").  This is a signal to the
higher-level system that it should trigger whatever it thinks best for
disambiguation (maybe refresh from keyservers, log the problem, or punt
to the user for confirmation?)

If no key is already valid for any User ID that maps to $EMAIL, gpg
should craft a TOFU certification (see above) and return 0 ("association
mapped").


I think this is the minimal interface that we'd want to expose, and i
think that higher-level tools could make sense of it.  Tools that want
to use TOFU in a key selection sense would just use the standard gpg key
selection mechanism of "<john at example.org>" (though maybe we'd want to
improve that search mechanism by ensuring that matching keys are
returned in order of highest-uid-validity).

I'd love to hear feedback on this, or what sort of use cases it might
miss.

        --dkg

[0] https://www.debian-administration.org/users/dkg/weblog/98