TOFU - motivation
Neal H. Walfield
neal at walfield.org
Tue Mar 31 20:26:48 CEST 2015
Hi,
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.
Implementing the logic in GnuPG has a small trade-off: it's not quite
the right level of abstraction. That is, it is probably easier to
implement TOFU in an MUA. For instance, if there is a mismatch, the
MUA should dialog asking the user what to do. This requires that
GnuPG make an upcall to the MUA. However, the previous arguments are
stronger.
Neal
More information about the Gnupg-devel
mailing list