[liberationtech] the 14th reason not to start using PGP is out!

[elijah]

On 11/20/2013 07:30 PM, carlo von lynX wrote:

>     But wait, didn't Thunderbird just store a draft? Yes, and since I
>     happen to have IMAP configured it stored the draft to my server. Did it
>     bother that I had checked the flag that I intend to encrypt the mail?
>     No, the draft is on the server in the clear.

This problem is fixed in next generation approaches to SMTP & OpenPGP, 
such as mailpile and LEAP.

> I also recently had noticed that keyserver lookups are in cleartext by
> default, which is utter madness, but that at least is being fixed and
> there is good info on how to do so in [65].

Yep, an artifact of tools built in a time when not enough people were 
cognizant that meta-data protection was as important as content 
protection. I mean, heck, OpenPGP is designed to publicly expose 
metadata. No one would design a protocol that way now, least of all 
Zimmerman.

I don't need to beat a dead horse, but nearly every email from carlo 
contains one or more logical fallacies. This email contains two: the 
strawman fallacy (enigmail has poor security, so no usage of OpenPGP can 
have good security) and the composition fallacy (hkp keyservers are part 
of how OpenPGP works, and they leak metadata, so you can't protect 
metadata with OpenPGP).

No one is arguing that the way people commonly use OpenPGP with SMTP is 
a good idea. The question of the hour is whether it is a better strategy 
to spend time fixing secure email or to ditch it altogether and start 
something new. As it happens, we can't accurately predict which option 
will create the most security for the most number of people because 
there are too many unknowns. In this environment, the only sensible 
approach is to work on both projects: improve email as much as 
technologically possible, while also researching post-email solutions.

Fortunately, there are plenty of interesting projects working to 
radically rethink secure email, including LEAP, mailiverse, mega, 
parley, scramble, and startmail. Happily there are also plenty of 
interesting projects working on a replacement to email, including pond, 
darkmail, opencom, bitmessage, and flowingmail.

Essentially, the arguments against ever fixing email boil down to this: 
it is unacceptable to offer communication without deniability, 
unauthenticated non-repudation, end-to-end PFS, and end-to-end metadata 
protection. I agree that these properties are not possible with existing 
OpenPGP. I don't agree that these properties are absolutely required. 
With today's technology, we can achieve metadata protection and PFS with 
provider cooperation, and that is probably good enough in the short term 
(e.g. enforced StartTLS via ratched DANE). Regardless, you can 
potentially achieve all these properties while still using SMTP as a 
transport mechanism.

-elijah