TOFU Design

[Neal H. Walfield]

At Wed, 22 Jul 2015 12:01:41 +0200,
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.

This is related to another email that you sent in this thread and to
which I just followed up.  Let's continue the discussion there.

> > 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 don't see why we should implement TOFU for hostnames.

This also open an opportunity for an attack.  If the attacker just
replaces the @ with a similar looking character, we'll ignore the
key.  I don't think that's a good idea.

> > Verification
> > ============
> 
> 
> >   - If no bindings contain either the email address or the key, then
> >     we ask the user whether to accept the new binding.
> 
> 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.

This is a good idea.

> > 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.

Ok.

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

I think reasonable people can disagree about this.  But, as Robert
said, let's defer this discussion.

Thanks!

:) Neal