Pretty Easy Privacy - Conflicts with Autocrypt? No protection except...
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
Menu
▾
▴
If I understand what I'm reading about Pretty Easy Privacy from their proposed drafts, it seems incompatible with autocrypt. The methods of key transfer are different (metadata for autocrypt, mime attachment for PEP).
Additionally, header protection seems fundamentally flawed.
PEP only protects the "Subject: " header and only if it is encrypted.
On the other hand, autocrypt/memory hole protects the "Subject: " and the "To: " and the "From: " fields. Autocrypt/memory hole protects these fields as a MIME field that can be signed, encrypted or signed and encrypted.
Why have two competing standards, especially when one is clearly better?
It could be possible for PEP to improve and to have both, but then you have e-mails sent with protected headers as a MIME, redundant header of just the Subject in the body (maybe).. and how do MUAs interpret this? What do they display? The message body will re-list the Subject if the MUA does not know what to do.
This seems like a backslide into PGP/In-line, where we get "- " and "~" stuffing and PGP data at top and bottom of actual message body.
And then you will be sending keys redundantly.
Finally, let's not forget that PEP automatically generates keys so that you have to import your real keys and delete the auto-generated ones on every machine for every account you use.
How on earth is this "easy"? Why not have a pop-up that says "I already have a key / Generate my keys"?
I would not call the two incompatible. pEp implements key transfer as defined in RFC 3156, section 7. If you attach a key in Enigmail (with or without Autocrypt), you get the same.
Autocrypt defines a new header containing information about the sender's key. Nobody says that you can't do both or neither.
Autocrypt does not define protection of headers, Memoryhole is not mentioned in the spec.
Autocrypt is a standard, Memoryhole is a document that I'd call at best "work in progress", and pEp is an engine. That's a major difference.
Just like with Autocrypt. Both send the key in every message.
That's a known bug in the engine that will be fixed.
Thank you for your reply and pointing me to that PEP is following RFC 3156. I kept coming across examples of encrypted messages of PEP 1 and decrypted messages showing nested structure of PEP 2 and was operating on guesswork.
I'm fairly sure the Autocrypt people took over Memory Hole, right? The incoproration of it or protected headers is on the horizon.
I can understand PEP doing basic defaults for all and whatnot. I may not like some of the choices, but as can be seen with WireGuard simplicity goes a long way.
It'd be nice to see some merger in any case. It seems onerous on app developers and add-on developers to support both types of protected headers, but I imagine crypto users like the idea of all headers being protected and even if in a signed-only message (I use these at my job).
Concerning header protection, the fundamental idea (at least with pEp message format 2, which is used by default) is to enclose the inner message like a forwarded message, which means integrity and confidentiality of the entire message can be ensured.
If you include sender and recipient fields, you can also detect differences (e.g., tampering) to the envelope outside -- that's to be seen in context with our trust rating system, which includes states and UI mappings for manipulated messages. By default, pEp signs and encrypts the whole actual message.
A clear disadvantage from a privacy perspective of adding further header fields to the outer message about (abilities of) your communication partners -- if you (DKIM-)sign those fields or not -- is that we're talking about data which you can use in legal mass surveillance based on meta-data, like we have, e.g., in Switzerland with the BÜPF / LSCPT law including data retention for six months. By March 1 2018 this law was extended to be applicable to all email providers based in Switzerland, at least for those with significant large user bases. Also for secret services with a global reach, you can expect the focus to be on meta-data and not on (encrypted) MIME parts.
Another point concerning interoperability, by instance for the subject, is that for pEp messages you can at least grasp the intended subject displayed inline while with Memoryhole you need support for it in other PGP clients which know nothing about Memoryhole or pEp. That specifically is an issue in organizational environments using implementations like, e.g., Symantec PGP. Importing a key from the attachment in such environments is also easier than from the header fields.
But well, we're submitting our drafts to the IETF for the exact reason of having such approaches discussed, willing to do the right thing as long as privacy / confidentiality and interoperability are preserved, which are primarily goals as stated throughout the drafts; alongside that, we provide a reference implementation, which can be used as an engine with bindings. However, own implementations of pEp (in full or parts) can be created -- e.g., dealing with UI-friendly display of encrypted pEp subjects in Enigmail classic mode, which Patrick is already doing. That also goes in the other direction, the pEp Engine being able to process incoming Memoryhole messages, i.e., providing interoperability in here.
Last edit: Hernani Marques 2018-09-02
I don't want to disparage the work gone into Enigmail supporting both, which is a good decision. I am just baffled as to why PEP should even exist at this point and I disagree strongly with defaulting to PEP. Having support for PEP reading, like supporting reading DSA1024 mail even though DSA1024 keys are discouraged, is great, of course.
Why is it a bad default? It is the most zero touch experience a user can have.
If you know about gpg and want to go into more detail you can still do it.
New users on the other hand get pgp without having to learn stuff.
The "bad" part is autogenerating keys. New users who have Thunderbird on a PC and a laptop will end up creating separate keys on each and may not be aware they have a different key on each device if the keys are both identified as "kelly@g.com."
Like with instant messaging (take Signal, Threema, WhatsApp etc.) you cannot expect regular and novice users to even know anything about keys: that's the concept here. Despite that, already existing unexpired keys with sufficient length (>= RSA-2048) which you ultimataley trust yourself are expected to be used by pEp. If that doesn't happen (yet) that's a bug. This default behaviour is also mentioned in the drafts. However, by Patrick's decision already existing Enigmail users don't get pEp activated in the first place, so no new keys are generated as you need to opt-in for pEp. So the issue you mention might only happen if you have keys in your keyring without ever having had Enigmail priorly installed.
I'm one of the co-authors of the Autocrypt spec. Autocrypt did not take over Memoryhole. We moved the repository because the old location is no longer maintained - that's all. We did not discuss about incorporating Memoryhole, therefore any assumption regarding Memoryhole is just speculation.