[messaging] Advertising public key in email (was: TOFU to ease PGP key discovery)

[elijah]

On 02/10/2015 10:33 PM, Trevor Perrin wrote:

>> (2) We need a new protocol that allows a sender to advertise to the
>> recipient what their key is and that they prefer encrypted email. The
>> email signature is a good signal, but not ideal because there is no real
>> binding between the fingerprint on the signature and the email address
>> (unless the provider is in the habit of uploading signatures to the
>> public keyservers). The OpenPGP header has the same problem.
> 
> Could you expand on what's wrong with existing methods?
> 
> Do you just want to convey the sender's public key?  If by OpenPGP
> header you mean [1], that allows sending a fingerprint and URL.
> That's unfortunately similar to a web bug, but maybe the recipient
> could defer fetching the key until they need it to encrypt?

In the short term, we are supporting the OpenPGP header if the URL
matches the sender's domain, and we delay actual key fetching until the
user sends an email. It is a good idea to delay fetching for several
reasons, to prevent email bugs but also because you don't want someone
to be able to fill up your keyring simply by sending you a ton of email
with different keys.

There are a couple problems with the OpenPGP header. I could craft an
email that purports to be from trevp at trepv.net with an OpenPGP header of
my choosing. Maybe the recipient's client is smart and only accepts
OpenPGP header when the from header is DKIM signed. Even in this case,
both the sender's server and the recipient's server could inject a bogus
OpenPGP header. Maybe the sender's server should DKIM sign the OpenPGP
header, but it doesn't really have any basis to verify that it should.

All of this is too messy. It would be much better to have a header that
just specified a list of well known discovery/validation mechanisms.
E.g. DANE, webfinger, keybase, CONIKS, etc. The mechanism would need to
include some implicit or explicit endorsement of the key by the email
provider or central authority or central audit log or quorum/consensus
(so, for example, a fingerprint or arbitrary URL would not suffice). The
header might be added by the provider or the sender's MUA, so multiple
instances should be supported.

When the dust settles, and we all join hands and rally around the one
true system for automatic key validation, then there is no need for such
a header. But that day may never come, or will be a long way out if it does.

I also heard some people are partial to in-band approaches :)

> I'm not sure PGP signatures contain the public key or a full hash by
> default - so you may be right that signing by itself is insufficient
> (signatures don't necessarily "bind" the public key - see
> "duplicate-signature key selection" [2]).

Interesting, although I was just thinking of the same problem as with
OpenPGP header, that anyone can create a key with trevp at trevp.net for
the uid, upload the key to a keyserver, and send an email "from"
trevp at trepv.net, signed with that bogus key.

Enigmail will let you quickly fetch the sender's public key by
fingerprint from the keyservers if a message is signed and you don't
have the public key in your keyring yet, which is kind of nice. I assume
it only verifies that the downloaded key actually has that fingerprint
if you are running the newer versions of gpg that do this for you.

> Or do you have other goals?
>  - convey a key directory where updated keys can be found?
>  - convey a signature over the sender's email address?

I was thinking of these as separate and specific to the particular "well
known" mechanism.

Our model is that key updates can happen from any mechanism that is of
equal or higher 'validation level' (where we define a scale and
categorize each class of mechanism). We would not limit updates to what
was in that first header, but it certainly provide a hint as to where to
look.

-elijah