Re: [perpass] OpenPGP mail/news header

[Elijah Sparrow <[e-mail]>]

On 08/28/2014 07:00 AM, Simon Josefsson wrote:

> I have updated a six (!) year old document describing the OpenPGP
> mail/news header field.  As it encourages and promotes use of
> encrypted/signed email, I thought it would be relevant to this list.
> All feedback is appreciated, either directly to me or here.
> 
> http://tools.ietf.org/html/draft-josefsson-openpgp-mailnews-header-07

I am excited to see that you have resumed work on this. There are a ton
of projects working on new forms of 'easy' secure email, and they are
all experimenting with, or planning to experiment with, new forms of key
discovery and validation [1]. The nearly universal goal is automatic key
management without the need for user intervention.

I think that the OpenPGP header, or something like it, could plan an
important role in bridging what we have now to some of the ambitious
schemes proposed for the future (e.g. ppe, nyms.io, CT for email, dime,
etc).

There are some things that some projects have said they plan to do that
are problematic, for example attach the sender's public key in every
outgoing email or use the fingerprint from the signature of signed
messages to discover keys (since these are easily spoofed by a MiTM).

Everyone wants to get away from the WoT and from CAs. I think this is
good, and that an OpenPGP header could help facilitate this, if it was
written with a slightly different intent.

Currently, the goal with OpenPGP header is simple untrusted
advertisement. As the draft makes clear:

> Because the mail header is typically not integrity protected, the
>    information conveyed in the OpenPGP header field MUST NOT be trusted
>    without additional verification

With some slight modifications, I think the OpenPGP header could support
the kind of thing that many of the new generation of email security
projects are looking for, namely a secure in-band user-to-user mechanism
for key discovery and a way to validate this key with the service
provider when supported.

Although it is *usually* the case that headers are not integrity
protected, they certainly can be with DKIM, which is growing in
popularity (as gmail is going to effectively be forcing it on everyone).
Even without a DKIM signature, a client could validate the advertised
key with the provider if the header provided some clues as to how this
could be done.

Unfortunately, I don't think these 'how to validate clues' can take the
form of an arbitrary URL. As you note, arbitrary URLs are problematic in
that they can effectively be used as 'email bugs', tracking who received
the message and when it was received. Also, an arbitrary URL can be
completely bogus.

For example, something like:

   provider-endorsement: webfinger, dane

is better than

   provider-endorsement:
https://example.org/.well-known/webfinger?resource=acct%3Acarol%40example.org

Even if the headers are completely unsigned, a client can be smart
enough to say, "aha, I understand webfinger, so I will contact the
domain in the 'from' email address and query webfinger via https".

Provider endorsement of keys is not ideal, but I think it is an
important stepping stone toward what we eventually want, and also it is
much better than plain TOFU with zero attempt to validate. Once clients
are accustomed to provider endorsement, these same clients can be
written to audit their providers to ensure they are not advertising
bogus keys on their behalf. In what form this auditing will take is the
topic of much discussion (everything from network perspective, n-of-m
consensus, or a Certificate Transparency style append only log), but it
would be good to create an OpenPGP header that can lead us in that
direction.

Many people will rightly object that provider endorsement is limited
because it requires participation from the provider. On the other hand,
there is a rapidly growing list of provider who plan to offer OpenPGP
encrypted email (including, of course, gmail and yahoo). Many of these
models are not great, and the private key is not kept secret from the
provider, but provider endorsement could still be useful in these cases
in the interest of interoperability.

Perhaps what I am describing warrants a separate header. I think it is
close enough that it would make sense to combine with OpenPGP header.

In the case of LEAP, we have implemented support for the OpenPGP header
in the automatic key manager of our client, both sending and receiving,
but we are not going to support arbitrary URLs or key ids. It is 2014,
after all, and there is no reason to not use the full fingerprint,
especially since this is intended to be read by machines.

-elijah


[1] https://github.com/OpenTechFund/secure-email (pull requests welcome)