TOFU Design

[Daniel Kahn Gillmor]

Hi Neal--

thanks for working on a TOFU mechanism for GnuPG, i think it's a great
plan!

On Wed 2015-07-22 06:01:41 -0400, Werner Koch wrote:
> On Fri, 17 Jul 2015 14:24, neal at walfield.org said:
>
>> Finally, we'd have to regularize names.  At least for latin and
>> germanic languages, UTF-8 canonicalization, space compression and down
>> casing should be enough.  But, I'm not sure about other languages
>> where letters are combined.
>
> Just to clarify: GnuPG only knows about UTF-8 (as per OpenPGP) and it
> does not handle IDNA etc.  Any mapping to the encoding required for
> example by rfc822 has to be done outside of GnuPG.
>
>> Note: it is unclear what to do when the OpenPGP User ID is not in RFC
>> 2822 form or there is no email address.
>
> I suggest to ignore such a user id.
> See gnupg/common/mbox-util.c:mailbox_from_userid on GnuPG parses userids.

I agree with Werner here.  If we're doing TOFU, there are potentially
many contexts in which to do TOFU.

By default, gnupg could implement TOFU only in an "e-mail address"
context.

the other obvious context to implement would be an "exact User ID"
context.  Applications using this mechanism would know by default which
context they're in, and the databases could be distinct.

I'd start with the "e-mail address" context, and i think your general
outline loks like the right one to me.

fwiw, i also think that we should match e-mail addresses after
downcasing both the local part and the domain part of the e-mail
address.  I've been bit by this too many times!

It's conceivable that for well-known domains that offer particular rules
(e.g. gmail's dot-injection mappings that treat foo.bar at gmail.com and
foobar at gmail.com the same, or common +suffix mechanisms mapping
foo+anything at example.com to foo at example.com), a pragmatic TOFU "e-mail
address" context could retain a set of domain-specific normalizations
that it's willing to apply before doing its search.

> For TOFU alone this would be okay but TOFU is only one part of the
> story.  We need to limit user interaction to the bare minimum.  Thus in
> this case we need to lookup the key using DNS (PKA style CERT records)
> by th mail address.  The binding should have a "Initial-Source" field to
> record that the binding has been created from
>
>   a) PKA
>   b) keyserver lookup by fingerprint
>   c) a key send with a message
>   d) the verification of a signed message
>   e) a manually imported key with verified fingerprint (keysigning).
>
> This information can be useful in cae of a conflict.  For example a
> manually imported key should be more trustworthy than one take from a
> keyserver.  The exact rules need to be worked out but tracking the
> source needs to be there right from the beginning.

i agree that if the TOFU db is going to have relatively flexible data
storage (and if the db isn't exported publicly), keeping this info
around doesn't hurt much.  otoh, i'm not convinced that there's a set of
logical rules/policy that make sense for how to use it for most people.
But having it makes it possible to experiment with possible rules.

>> course, for new bindings, the key is probably not yet available and if
>> the user hasn't enabled auto-key-locate (which is disabled by
>> default), then we can't do the verification nor can we update the
>
> We need to change some of the defaults - at least for email use.
> Traffic patterns are anyway not protected and thus it does not sense to
> avoid network access by default.  For those who need it they can use
> --disable-dirmngr to avoid all kind of network access or use the
> proposed --enable-tor option.  The goal is to increase the use of
> encrypted mail and not to be safe against targeted attacks by default.

I disagree here.  Users who want automated key discovery could have lots
of ways that they want to do it, and not all of those ways are as
privacy-preserving as they could be on the network.  I wouldn't want to
see these defaults changed automatically.  Maybe they'd be changed
explicitly as part of the user opting into a TOFU scheme (i.e., when you
opt into TOFU, you have to also choose what sort of network-discovery
profile(s) you want to enable)?

For example, when Alice send e-mail to bob at example.com, and Bob doesn't
have an OpenPGP key at all, automated network checks imply that Alice's
MUA would leak her interaction with Bob to the network *every single
time* she sends him an e-mail.  Unless her key lookup queries are done
via the same exact channel that her e-mails are sent (e.g. see
draft-moore-smtp-addrquery), this is a significant additional negative
privacy impact.

I do want increased use of encrypted e-mail, but i don't want users of
encrypted mail to be subject to *worse* privacy situations than people
who don't use encrypted mail.

>> Export
>> ======
>>
>> Should TOFU bindings be exportable?  TOFU reveals the user's social
>
> No.  That should be kept local like the trustdb.

I agree with Werner and Robert that TOFU bindings should be kept local
to the user.  We can talk more later about whether there might be
scenarios where one might want to publish such a binding, but the
default should certainly be "no".  There's enough good stuff to work on
here without trying to wade through the tradeoffs and implementation
details around publication.

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20150804/11083052/attachment.sig>