K-9: attached OpenPGP key thoughts

[Valodim]

The general idea of attaching an openpgp key to a mail is to inform a
communication partner about one's key, for the purpose of verifying signatures
and possibly to encrypt a reply. this bypasses the need for a keyserver lookup,
but also adds some 10kb to an email which is quite some overhead.

There are a couple of ways to implement the general idea of sticking one's
public key into an email, with varying levels of user involvement, adherence to
standards, among other differences.

To start off the discussion, the first distinction and decision I would like to make
is whether the key should be part of the mime structure, or in the pgp data. In
the mime structure it's a regular old attachment like any other, this is already
used here and there, e.g. in the Web.de App (and I think supported in current
stable?). Putting the key in the pgp block will basically stick it next to the
signature data, where it will only be exposed to the pgp backend. Thoughts:

in the MIME structure:

• more established (because it's not a new idea)
• if the user agent doesn't handle the key itself, the user can still import it
  from the attachment (good for user-involved workflow)
• users who don't have pgp get two weird attachments instead of one (bad for ux)
• the attached key is part of the mime structure, so handing it to the pgp
  implementation leads to more complex data flow (implementation complexity)
• keys meant to establish pgp-communication can't easily be distinguished from
  an attached key for somebody else (bad for implementation complexity)

part of the PGP data:

• both signature and pubkey data are passed to the pgp implementation with no
  further effort
• purpose of key is clear (good for implementation complexity)
• no visible pubkey attachment for the user to open and import (bad for
  user-involved workflow)
• useless unless implementation-supported, unexpected keyblock might produce warning (I tested this: gpg gives a warning, which is shown in mutt but not in enigmail. openkeychain silently ignores the block.)
• only possible for emails which are at least signed

I think for establishing encrypted communication in an opportunistic way, the
second option is the way to go. I would really love to see this working to
allow keyserver-independent, tofu-style pgp encryption between K9 clients.

I'll leave it at this for now, but would love to hear some thoughts. (also ping @dschuermann, @dkg. also probably gonna crosspost to openpgp-email ml)

[dschuermann]

I am in favor of solution 1 as this is supported by Enigmail and WEB.DE/GMX.DE.
Changing to solution 2 requires coordination between all apps/providers, I think this is too much effort at this point.

[Valodim]

I disagree about your point about coordination. The coordination effort is the same for both, what's different is the implementation effort.

I also wasn't clear about this above, but I thought about this for a while from an implementation point of view: I don't think there is a chance to get reasonable opportunistic communication properties with option 1. (I should elaborate on this more but gotta go for now)

[dschuermann]

Ok, then I haven't really understood this discussion. Enigmail etc are currently supporting import of pubkeys from attachments, while solution 2 is not supported. What am I missing currently?

[philipwhiuk]

Maybe all my contacts are on the key servers or maybe I'm missing something.

If I get an email like this one: http://www.securityfocus.com/archive/1/537977/30/0/threaded

K-9 tells me it's signed. I can import the key into OpenKeychain and then OpenKeychain allows me to encrypt an email using the key.

What am I missing that I'd be able to do if HPe attached a file when they sent the email?

[Valodim]

@dschuermann enigmail does not import attached keys automatically (to my knowledge), and it's questionable if it should. requiring the user to manually import keys however is a) not exactly opportunistic in the sense that it works without user interaction, and b) loses the intended "use this key" implication made by the attached key. Attaching a key automatically is also problematic because it's yet another weird attachment.

@philipwhiuk There is a surprising number of people who don't want to have their key on the keyservers. But apart from that, losing or at least reducing the dependency on keyservers is imo very desirable: They cause ux issues through lookup times and introduce a connectivity requirement, it seems likely that the entire ecosystem is quite easy to DoS should someone put their mind to it, and they also have serious privacy implications both from the upload, and the leaked metadata if we were to automate the key lookup for signature verification.

I'm not saying this is completely vital. But I think there is untapped potential here to establish secure communication without bothering the user about it or relying on a sort-of-centralized infrastructure for key lookup. Disregarding interoperability for a second, if I attach the public key block to the signature made in opportunistic mode, I trade 7kb of email size for a tofu-secure communication between two k9 users with no keyserver lookups after the first email. Taking interoperability back into the picture, this does not affect enigmail. Didn't test with mailvelope yet, but I would be surprised if it broke anything.

...maybe I'm just overthinking this.

[philipwhiuk]

Yep, I mean if it's necessary for that to work I'm for it. I want PGP to work like Signal, the encryption as transparent to the user as possible and simple to use.

(I'm just saying I wasn't that aware my device was looking on key servers as is - I don't want it to be necessary to need key servers otherwise you're basically saying OpenPGP is just SMIME really - with servers that start to look like CAs).

[dschuermann]

@Valodim It wasn't clear from the beginning of this discussion that you want automatic key import. No email client I know has that currently. Engimail allows to import the attached key by righ-clicking it and WEB.DE/GMX.DE show an additional button to import the attached key (btw I tested WEB.DE with two key attachments and only "the first" was imported).

Why do you think it's questionable if Enigmail would import attached keys automatically?
I am still not 100% sure what you are proposing right now :grimacing:
Add pubkey to PGP part and import it automatically?

[Valodim]

I'll split off the "automatic import" aspect here, for which there are three distinct approaches:

1. Purely manual import of keys. This is what we have now, the user will always have to click "download key" for any crypto (including signature verification) to happen. Since this happens interactively, it sidesteps both the delay and privacy issues of keyservers, since the user takes responsibility for the action themself. This is an okay-ish solution.
2. Automatic import of keys from keyserver. This is possible with no help from the sending side, would allow verification of signatures, and subsequent use of keys for opportunistic encryption. However, it is (I think) impossible to implement in a way that isn't detrimental to the user experience, because the download may take arbitrarily long or even fail. There is also an involuntary leak of metadata.
3. Automatic import of attached keys (disregarding the position in the mail structure for now, let's just assume they are available to the openpgp provider). Adding the simple criteria that this only happens for keys which are used to sign the mail, the potential for abuse seems limited - might still be worth marking those keys as auto-imported, or giving the user an opt-out option. This case gives us signature verification and establishes opportunistic encryption, with the drawback of increased email size.

I think I would go for option 1 over option 2 because the ux there is just too inconsistent, but we lose nothing supporting option 3.

[gdt]

In the "automatic import" sub-area, I think keyserver fetching and the "involuntary leak of metadata" is over a bright line of respecting user privacy and is just out of the question as a default.

I would make 'automatic import of keys in mail' an option and default to off, and a separate option to include one's key in outgoing signed mail. Is there an IETF standard for this?

In my experience of OpenPGP and trying to get others to use it, the key exchange part has been not a big deal. It's all been about 1) wanting to bother and 2) having an MUA that works well enough not to be annoying.

[Valodim]

re automatic fetching by default: Yes, we definitely can't do that.

[dschuermann]

Option 1 is implemented, but I miss option 4:
manual import of attached keys:
Yes it's possible currently, but we could easily switch to a much better UX like WEB.DE/GMX.DE where a big nice button is displayed, something like "You have been invited to secure email communication. Accept?" and not showing the key inside the attachment section.

That said, I generally like option 3 (with the requirement that the key is a MIME attachment). I fear that it requires more thought about OpenKeychain's current trust model, because attackers now can easily insert keys into the db, which are shown as "orange" and in K-9 with 2 circles. A second issue which comes to mind is the case where more than one key is attached to an email. If we sort out these two issues, I would definitely prefer automatic import.

[Valodim]

"easily insert keys": well yeah, that's the whole point of the "orange" status of keys - there is a key, but it's not verified. orange is still strictly better security than red since it prevents passive eavesdropping, and that's already the 99% case.

more than one key: import the one which signed the mail

[gdt]

I think the auto-import is more subtle. Orange isn't strictly better than red, because a user may send information to an unverified key they wouldn't put in the clear - but maybe that's a bit too much paranoia.

The idea of importing only the key that signed the mail is a good one. I would further suggest that it have to have a uid that matches the From: address.

[sc-perth]

I submit the following wrench in the "import the key that signed the mail" plan:
I have a master key, which has three sub keys, each sub key can only do one of the 3 functions (signing, encryption, authentication). If only the signing key were to be auto imported, then opportunistic encryption would not happen with me; though automatic verification would. I'm under the impression that this setup -- offline master, distinct function sub keys -- is becoming more normal. I do it this way because it's seamless for me with my yubikey & purportedly provides better security.

I would suggest that the proposed automatic import be complicated to: identify all attached keys used to secure this e-mail, import all of them. That said, I'm not e-mail savvy enough to know if that will become an issue should there be multiple replies from multiple participants. Perhaps going the route of MIME attachments to attach the key key would cause previously attached keys to become stripped preventing this issue (replies tend to not include attachments, while forwards do).

Here's wishing this feature request the best :)

[rugk]

1. Why can't we use both the S/MIME and "part of the PGP data" way?
2. We should certainly try top get more clients to do the same (especially if we use the "new" way of attaching the PGP key to the PGP data).

For the second I've asked different other FLOSS mail solutions, whether they (plan to) implement this:

• PeP (I think currently they support the first method)
• Mailvelope

[rugk]

As discussed on Twitter with PeP guys, I'd be nice if K9 mail would support at least importing the import of "PGP data"-attached public key (calling it "hidden" attached public key here - as it cannot be seen by users, who do not support PGP).

[lbdroid]

I think that auto-imported keys (if they don't already), should show a special "signed, but not verified" output to indicate that the key isn't trusted, and MUST NOT be used for encryption until the user HAS taken manual steps to verify the key, such as a voice call to confirm the fingerprint. The user will, of course, have the option to mark it as verified without taking the manual verification step, but it will be clear to the user in that instance that what they are doing may not be safe.

[brenthuisman]

I disagree that the key MUST be verified before use. It limits the use of encryption, while not adding anything. Anyone who wants to verify keys can already do that before sending, and will be able to still under the proposed change.

Any default that increases the number of encrypted messages is a good default in my opinion. Therefore, alignment with the pEp protocol would be very welcome. Also, since K9mail claims to support Autocrypt, shouldn't this be the default behavior already?

[dschuermann]

Yep, this is a very old issue and superseded by the Autocrypt spec.