Convenient End-To-End Encryption for E-Mail | Hacker News Reader

Convenient End-To-End Encryption for E-Mail

autocrypt.org

311 pointsdoener183 comments

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy.

Why? Because:

* It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.

* Email encryption is never forward-secure. The most popular standard, OpenPGP, involves a long-term key that is the root of secrecy for all messages from a particular person. Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system.

* Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simply content. They're sent in plaintext. We would never accept a new secure messaging system that behaved like that.

* Most email users get their email from a website. Unless you make them install something on all their computers --- and at that point, just get them to install Signal, WhatsApp, or Wire --- "encrypting" their email involves schemes in which those websites can get their plaintext mail.

* Most email clients are searchable-archive-by-default. Again, if you're using a secure messaging system to keep secrets from a state-level adversary, that's exactly what you don't want. And again, what matters here is the behavior of the overwhelming majority of clients. If you can stipulate a special mail client that is extra-careful, why not stipulate a forward-secure advanced messaging system and stop bothering with email?

Everything that makes email effective in the real world makes it inhospitable to secure messaging. We should stop trying to push this particular boulder up this particular mountain and instead just get people to adopt serious secure messengers.

The email address format is so useful for domain-based identity.

We still haven't squared Zooko's Triangle. What is the practical way to get a function like "document was sent with best effort for some legal purpose to a known party"? Are we just stuck with "login to the secure messaging site" emails from our banks?

Since it's incredibly unsafe to open document formats delivered over email in native viewers, we should be opening those documents on the web-based viewers on websites anyways. That's the most important advice we give at-risk users now: don't click.

There shouldn't be any difference. When opening it in a web page, you're just running it in the browser's sandbox.

How did it come to this? It seems like the web browser is doing the operating system's job. Were OS vendors just asleep at the wheel?

My pet theory is that OS vendors didn't really need a good sandbox. They could just tell you to be careful what applications you run. But, nobody would accept web browser developers telling you to avoid browsing unknown websites, so they were forced to build a good sandbox.

But, I don't really know. I'm just really disappointed by OS security.

There's an enormous difference, and it's not just the sandbox; it's also that the viewer application is:

* Written in a language other than C

* Doesn't have any access to your local system by design, not as a consequence of sandbox rules

* Is maintained serverside, so everyone gets patched instantly

Regarding your first point, would a website written in C and compiled to JavaScript have the same security issues? I'm wondering whether a middle layer can fix the problems you have with C, or if they're inherent to any use of the language.

It's the operating system's job to protect itself from userland, as well as to protect userland from other userlands. It's generally not its job to protect your documents from your applications.

Normal people don't worry about malware rooting their OS. Normal people worry about malware ruining their un-backuped photos and work docs, something that few operating systems dare protect users from.

(Which is why the iOS model of computer security is IMO a sleeper breakthrough, and why I always always recommend iPads/Chromebooks to people I wouldn't trust to not download Comet Cursor.)

Except that we went through this in the 1990s and:

1. Highly-interactive, programmatic, cross-connected documents were (security-wise) a Very Bad Thing.

2. Secure systems divorced viewing of documents from either editing them or running code. Mostly.

Windows didn't do this, and ended up with massive security issues, but the systems were largely not massively interconnected. Yes, they were on business LANs, and yes, there were connections to some other systems (largely through email), but not today's "everything is on the Web and you're connecting to 100s or 1,000s of remote sites daily".

Unix systems, generally, did enforce separation. They were also typically more interconnected (remote filesystems, ftp, telnet, early SSH, early Web), but there was some sanity in data/code separation.

Unix systems could produce and view Postscript and PDF documents. Windows systems ... mostly couldn't. If you wanted to view a Word document, you either printed it out, or you opened it in MS Word.

Microsoft did, yes, make a read-only viewer application. If you tried to, say, scroll through a document by hitting the spacebar, it would pop up a dialog telling you you couldn't edit the document. Every. Fucking. Time. You. Hit. Space.

I nuked that mofo so fast. "less" with catdoc or mswordview worked well enough for me.

I'm not claiming that 1990s Unix / Linux systems had sufficient process/data separation or sandboxing for today's network environments. They didn't (and we've got the scars to show for it). But they were following a more appropriate tack, and did in general foster environments where documents weren't openly dangerous.

(Again: mostly, there were exceptions, but they also pushed limits and took things in directions that weren't generally intended by the software designers, in sharp contrast to Windows.)

I guess I'm asking if you've written Signal or any other mode of secure messaging into a contract explicitly, in some kind of sufficient notice clause.

> The email address format is so useful for domain-based identity.

Agreed. But this is also where the problems of spam begin.

Perhaps if we chose to 'phase out' MX records in DNS for something new, say 'MSG'. A domain could then have an MX as well as a MSG server... A local MTA would route to the 'new shiny messaging system', so that clients could use the one system to read emails. Remote MTAs could also lookup and see if there's a 'MSG' on the receiving end and talk to it instead, rather than the designated MX, increasing the security. (In this case the sending user would still be sending via a normal email client)

Ideally, everyone will migrate over to MSG, upgrading the world smoothly.

(I figure something like this has already been tried tho...?)

2c.

Bayesian filters solved this problem.

My only email volume problem anymore is entirely opt-in / self inflicted. Some percentage of global bandwidth is still wasted on spam, but it is a vanishingly small proportion of traffic for that to matter anymore. ¯\_(ツ)_/¯

> Lose that key, ever, and not only is every message you send in the future unsafe, but every message you've ever sent in the past is too. That's a terrible property for a secure messaging system.

That's false. There are mechanisms for lost keys revocation. This is already a solved problem.

> Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simply content. They're sent in plaintext. We would never accept a new secure messaging system that behaved like that.

So do you have any other email-like system out there, not dependent on a centralized service, that does not leak meta-data?

> * Most email users get their email from a website. Unless you make them install something on all their computers --- and at that point, just get them to install Signal, WhatsApp, or Wire --- "encrypting" their email involves schemes in which those websites can get their plaintext mail.

Can you host your own WhatsApp server? You own Signal server? No. Having your own email account on a VPS is trivial and much lower effort to remain in control of your communications.

The point is that you dont use website to consult your email if you want to move to encryption. And Email has a lot more benefits than your typical IM - it's a standard after all and can be used every everyone on Earth, you don't need to rely on any app adoption curve.

Revocation doesn't provide forward security.

Standards are what we say they are; almost everyone can use Signal today, and we'd be better of spending the effort to make sure literally everybody can than trying to retrofit security onto SMTP email.

> almost everyone can use Signal today

Except that almost everyone does not. Yet everyone has an email address. I'd say you have to pick your fight. Trying to convert everyone to Signal, even though it will never replace email in what email broadly does and allows, or trying to add encryption to email.

First, I think you'll be surprised to find how many people use Signal Protocol today, since it's been integrated into one of the world's most popular messaging applications.

Second, you suggested that we try to retrofit security into email because "it's a standard". My argument, which you haven't rebutted, is that that doesn't matter.

> Second, you suggested that we try to retrofit security into email because "it's a standard". My argument, which you haven't rebutted, is that that doesn't matter.

It matters because you need to use email for about everything. Ever seen a bank asking you to register using your Signal account? Ever seen any government website relying on anything else than Email? It's pretty clear Email is the de facto standard and it matters because people have to use it anyway. So adding security to email is worthwhile no matter if it's not your only way to communicate.

It doesn't help us all that much that a lot of people are using the Signal Protocol since they're using it in several incompatible silos. Whereas virtually all people using email can communicate with each other.

I use the vanilla Signal. I cannot talk to users of Whatsapp Signal.

Also, there is value in email's address scheme. The person@organization.tld format is very convenient for identifying senders and recipients.

So keep it, and use it only for rendezvous for better systems, and for the automated transactional bullets that email is principally used for today.

I love signal and kinda-sorta agree, but

a) Right now Signal is oriented around your hpone # and while most people have phones, they come at a cost, are less easy to acquire than an email address, and much less anonymous

b) Signal (and slack and so on) organize conversations around individuals and groups, rather than around subject. That's OK for personal contacts (with whom you have conversational context) but not so great for many other contexts where you'd like things structured by subject

Signal != Signal Protocol. I like Signal and prefer it to the other applications, but Wire (for instance) does not need your phone number.

Wire does not need your phone number per se, but the Wire client on phones basically suggests by default to use your phone number as an identifier, if you create your account from your phone. That's a pretty poor way of doing things, especially if you are supposed to guarantee privacy.

> That's false. There are mechanisms for lost keys revocation. This is already a solved problem.

This is very dangerously wrong. Revoked keys decrypt old data just fine. Revocation is advisory. Your attacker will choose to disregard that advice and decrypt anyway.

> And Email has a lot more benefits than your typical IM - it's a standard after all and can be used every everyone on Earth, you don't need to rely on any app adoption curve.

The fact that encrypted email interfaces with plaintext email has resulted in a continuous never ending series of screw ups where the secret data email gets splattered in plaintext across the network. A secure network protocol is only secure if it's incapable of being insecure.

The keyholder can re-key / re-encrypt messages they hold against the new key(s).

Obviously: they cannot re-key / re-encrypt messages they don't hold that were encrypted against the now-untrusted key.

Do you see any ways around that? Doesn't key-based encryption of long-duration data intrinsically have this limitation?

> A secure network protocol is only secure if it's incapable of being insecure.

As long as an email leaves from your computer in encrypted form, what is the point of failure as long as you are careful with your private key?

on a vps? why? sounds like a great way to make sure at least one entity has access to your mails, encrypted or not, whether you keep your privkey on a diff machine or not

If your emails are encrypted on a vps, they might have access to it but they sure won't be able to decrypt them anyway.

Good points, but email is so entrenched it might be easier to slowly fix the issues rather than throw it all out.

Incomplete fixes only prolong the agony.

And where by "agony" we mean "innocent people being put at risk".

For what? So we can feel clever for someone having pulled off an elaborate retrofit we didn't expect we could accomplish? That's vanity, not engineering.

So we can feel clever for having actually gotten adoption, rather than feeling clever for creating a wonderfully-secure new system that can't compete with the network effect of e-mail.

It's possible that more bona-fide messages are sent every day with WhatsApp than with email, whose stats include (and, at least for me, are dominated by) automated transactional emails. I don't think "network effect" is as powerful an argument as you want it to be.

A large problem is that the companies with the money to address the issue will only do so starting from a position of a walled-garden rather than a system like email that in principle is open to anyone's mua/mailserver?

We have a proliferation of communication apps that don't talk to each other because each of the capitalistic driving forces wants to kill every other app so there's wins (even if there app is much worse than competitors).

This is where you need cooperation for progress and where capitalism, with greed as the driving force, utterly fails.

*their's, their

Your dimissive post boils down to “less than 100% perfect security is not ‘practicable’ so let’s leave a massively used, default communication platform utterly unsecure.”

At least three of your critiques of encrypted email could be made of HTTPS: it leaks metadata (what sites you visit and when), it is plaintext by default, and the archives of the secured material are persistent and searchable. Yet HTTPS is hugely valuable.

But the biggest issue with your critique is that it proposes treating secure messaging as a special case for which people should just use a special tool. The old, “just use Signal” nonsense. Guess what? People suck at knowing what communications need to be secure, and they suck at keeping mundane conversations from veering into sensitive territory, and they suck at moving conversations from one platform to another. As many systems as possible that they use need to be secured, so that WHEN they mess up — meaning, have the gall to say something potentially sensitive outside of infosec-land blessed tools — the consequences are mitigated.

Security professionals need to meet users where they are. And where they are, to a massive massive unstoppable undeniable extent, is on fucking email. Shitty, plaintext by default, metadata leaking email. Just crying out to be fixed.

And they’re on Twitter DMs and Facebook and god help us Slack. Which is why the people who made Signal put their crypto into WhatsApp. Not because it’s a GOOD IDEA to let Facebook (!!) broker your key exchange and see your metadata — yes, Signal protocol can’t keep metadata away from third parties either, not entirely — but because they had the chance to improve security in an imperfect but good way for millions of people.

The people behind autocrypt took a similarly honest stab at improving email security. If this sort of system were more widely deployed — and i know firsthand that gpg can work well when deployed to an entire workgroup — the security gains would be massive. A huge, imperfect gain. And an essential one even for people who use Signal et al — because every single one of them, dollars to donuts, uses email part of the time. It would be hugely wrong to just leave that on the table.

You seem to be relishing this takedown post. I don't want to harsh on that, since I enjoy writing a takedown as much as anyone, but I have to point out that you're attacking an argument I didn't make.

It's not my argument that people should use special secure messaging applications when they need security, and email at other times.

It's that we should stop using email pretty much altogether. Like I said: it's archaic. In the overwhelming majority of cases, a messaging application does a better job than store-and-forward email anyways. Which is why a lot of us look at our email inboxes these days and notice that most of what's in there is automated transactional stuff, with occasional cold inbound introductions that quickly transition off into some better medium.

The one thing we do still routinely use email for --- sending files to each other --- is an iredeemable security disaster that needs to end as soon as possible anyways.

> It's that we should stop using email pretty much altogether. Like I said: it's archaic

Sorry but have you ever used Signal or any other IM to send anything longer than a few sentences? Email can be as long as you want, and it is totally appropriate when you want to write a longer document.

Yes, I've used Signal and other messengers, including "IM's", to send things longer than a sentence. And, when I send email to people, if I have something more complicated than a paragraph or two to send, I make an actual document anyways. So what's your argument?

Here is something that I have a need of pretty often, but don't know how to do in things outside email (Whatsapp, Signal, etc): a point by point interleaving of the original message and the reply; for instance in a technical argument.

I could do this in Slack, but unlike email this is not even close to being universally supported.

For such technical discussions, I prefer an issue tracker, wiki, or forum. It should be a centralized searchable archive and not hidden in personal mailboxes.

Sure, you can use email as an interface to an issue tracker. Debian is probably the most prominent example. That is worse than anything web-based in my opinion.

That answer isn't workable for those of us in shorter term projects which lack that sort of infrastructure. The need remains for a flexible messaging system to take over for those kinds of messages that need some permanence. It sounds like what people familiar with email workflow want is the email a document interface so we have something tho point to after the fact. I don't think anything else does that though Wire may at some point.

Have you used Signal recently? It’s quite robust IMO, from texting to calling and everything in between. My initial reaction to the GP post was not unlike yours, but as I read on I find myself agreeing with him. Going through my email records, a vast number as he said, are automated or transactional. The only real exceptions are from older relatives sending Facebook crap, or occasional indications to and from friends who don’t use messaging apps to read a particular article or study.

Worse it’s pretty much impossible to teach people don’t want to learn how to try and make email less insecure. By contrast I found it very easy to turn people onto Signal and similar applications.

Yes, you can write as long a message as you want with signal. There are desktop clients. You can attach files. Or voice messages. Or use it to call them. Or video chat them. It’s a crazy robust full featured incredibly secure communications system.

It's a centralized system, with a single point of failure, and you cannot use it without a phone number.

Then use Matrix or wait for Wire to open-source and federate, but securing email has failed for decades now.

> There are desktop clients

You mean the ones with Electron, using 5% of your CPU idle, requiring you to have first registered your smartphone with it before it can even work? That's not what I call a functional desktop client.

I don’t know a single person who uses the desktop client, and there’s the rub: it’s fine if I can perfectly render a 1000 word essay on my huge monitor, but not one of my friends will want to read it on their mobile screen.

How often do you send emails longer than a few sentences?

I don't really see a problem with long messages on Signal. The only annoyance is that the desktop clients are always browser-based (Electron or website or plugin).

> How often do you send emails longer than a few sentences?

Actually every single day, and not just once. Maybe I am an outlier?

I’m pretty sure I want a big searchable archive, though. That doesn’t seem compatible with most of these security-oriented message schemes.

Protonmail seems to pull it off. Though at the moment encryption only works inside their system. They are actively working to implement the ability to send secure messages to people outside their service with GPG, though. I believe the CEO said it’d be ready by early 2018.

Please correct me if I'm wrong, but they don't let you search in a protected manner.

They enable searching of data they keep unprotected (the metadata so to speak)

And proton mail bridge seems to be an "offline" (i.e. offline to them) email search engine that you run yourself, so it downloads your emails, and makes them fully searchable, but to do that, is also keeping them in an insecure state.

compare to

https://www.cs.columbia.edu/~angelos/Papers/2007/SSARES_ACSA...

and

http://sprout.ics.uci.edu/pubs/05628733.pdf

I can search full text of my email on Protonmail.

At least I'm pretty sure that's what I'm doing.

Pretty sure you're searching the "metadata", who, when, subject

https://protonmail.com/support/knowledge-base/search/

Hrm. In which case, the metadata searching has proved fairly useful.

In the longer term / larger scale, it's not going to be sufficient though.

The local stuff isn’t necessarily insecure (depending on your paranoia level). The security of your computer system is totally unrelated to the encryption of your mail - even with GPG most people are keeping their private key on the same system they use to read their mail. Full disk encryption with something like Veracrypt or bitlocker or file vault or LUKS should be more than enough to keep your decrypted emails safe when you are not using your computer.

My guess is that bridge is run as a service. i.e. you make reuests via web site which are encrypted with local javascript (so that proton mail can't interpose), protonmail forwards to the service user runs which provides an encrypted response which local javascript then decrypts and displays.

In that case, you have to run a service that is always running that is effectively keeping the e-mails available in the clear. Is it better security than keeping them in the clear on a central server? sure. But is it really any different than running my own smtp/imap/webmail server on aws without encrypting any emails which I access? In practice it would seem to be a similar threat model and I'm not convinced many would view that to be particularly secure, just a tad more private.

I think it's naive to expect email to be replaced any time soon. Despite all the attempts over the years, it remains and persists. There are essentially no major ongoing efforts to replace it by any of the big players, which is what would be required.

IM is not a substitute and never will be.

Agreed. People have been trying and trying but like like traditional letters and snail mail people have been trying to replace that for years unsuccessfully as well.

There are use cases for all of the different methods and the level of security you require will usually dictate what methods you employ when it comes time to transmit any certain type of given message. The substitutes work for us based on convenience and preference and, for the most part, most people don't truly need secured end-to-end encryption for their daily correspondence (even though I personally think it would be a great habit to get into before it's an absolute requirement to ensure personal / private / public safety).

Things like Signal are steps in the right direction but I only see a few notifications a month about friends and family joining. I'm not seeing rapid enough adoption from the "every (wo)man" to indicate that the public at large sees the need for end-to-end encryption, yet. Since we already got Snowden's revelations I'm not sure that time will ever come. Frustrating, it is.

> It's that we should stop using email pretty much altogether. Like I said: it's archaic.

Claiming that some piece of software or set of protocols is archaic is probably the least persuasive way to argue against continuing use.

> [...] with occasional cold inbound introductions that quickly transition off into some better medium.

Cold inbound introductions alone are a reason for continuing plaintext email well into the future.

It's surely somewhat more persuasive than merely calling a constructively-argued position you disagree with unpersuasive.

> a lot of us look at our email inboxes these days and notice that most of what's in there is automated transactional stuff, with occasional cold inbound introductions that quickly transition off into some better medium

Just wanted to point out: that's certainly not true for everyone. The overwhelming majority of my work communication is done by email, and an important part of my social communication with friends and family also is. Yes, even with long-time colleagues and friends. Not everyone is using, or wants to use, other messaging applications.

> It's that we should stop using email pretty much altogether.

Is there another communication system that is decentralized (no single point of failure, no central place where people have to register, I can run my own server and customize the client), and is also widely used?

>Is there another communication system that is decentralized (...), and is also widely used?

XMPP, maybe?

In rhe Eastern Europe XMPP is widely used for online drug purchases, even widely than telegram, which unlike XMPP requires burner phone to register.

Is this an argument against any decentralized communications?

No, just an interesting tidbit of information regarding XMPP.

Thanks for sharing, that's quite interesting IMO.

I don't see it as a knock against XMPP, just an interesting tidbit of information and an example of a wide-spread use case.

Moral opposition to drug use is irrelevant here, people want to get high and will find ways to do so, I think the usage of XMPP in Eastern Europe is a great example of why cryptography is important, and why everyone should have access to encryption.

The fact that telegram is used in Eastern Europe for drug purchases is very interesting as well.

It's a good thing people know how to use XMPP and can use it at will for anything they wish, including online drug purchases. Which are going to happen regardless of moral opposition, encryption centralization/decentralization, etc.

Like it or not it's a valid use case.

>Just wanted to point out: that's certainly not true for everyone.

Very true. I use email for almost all my communication. It's not because I refuse to use anything else. I'm very much open to better solutions. But messengers linked to phone numbers can never be that solution for me.

Phone numbers come with way too many strings attached. They are country specifc. They can only be linked to one SIM card and one device at a time and that is almost never the device I want to use for written communication. They are subject to onerous contractual agreements and restrictions imposed by phone companies. By default, they allow everyone to call me. I don't usually want to be called on the phone.

I'd argue matrix.org is a good contender for that space, federated, selfhosted and steadily growing, with megolm for end to end encryption (based on signal axolotl whatever the name is).

Not specifically to you, but want to point out that you cannot have secure + decentralized + anonymous without being subject to poisoning attacks.

And "secure" is only relative to "convenient" for the most part. Most people will sacrifice the former for the latter.

I have colleagues and students that don't use smart phones. As much as I agree with your sentiment, the unfortunate truth is that right now there isn't a good drop in replacement that we could move to.

Signal is drop in for WhatsApp and I can tell everyone I talk to on WhatsApp to just contact me on Signal instead. What do I tell people to move to from EMail?

WhatsApp is an ok substitute for Email in my opinion.

Sure, it is not open source and but federated. Signal, Wire, Matrix, etc should catch up in the next years.

What do you need from Email that a messenger lacks?

I guess you only use a cellphone then.

Whatsapp desktop/web is terribly slow and requires your cellphone to be on at all times. Also, you cannot have whatsapp desktop/web active on more than one computer at any time.

Also, I do have several identities (work, leisure, even one-offs for website registration/communications) and no, I don't want to give my personal cell number to everyone.

> Whatsapp desktop/web is terribly slow and requires your cellphone to be on at all times.

They have a rather sound reason for the cellphone requirement, though. It's because the messages are stored only there and the desktop/web application is just a gateway to your phone.

https://faq.whatsapp.com/en/web/28080002

This seems like a more secure way to do it than what the others do, which is to store the messages in their servers.

Yes, but it means it will never be an email replacement.

The people without smartphones that I work with can use email.

I can get to my email anywhere, everywhere, whether I have a phone or not.

Of course that may be considered an anti-feature from the point of view of security, but it explains why IM apps can not replace email.

> What do you need from Email that a messenger lacks?

Discussion threads. Say I work on two different projects with the same colleague, or that I am also friends with a coworker and do things together outside of work. In whatsapp the different topics would all be mixed together into a big mess. With email I can just reply to a particular thread.

I prefer Telegram now but this should work in Whatsapp as well:

Just create a group for each context and name them properly.

Huh, i think you've just identified (for me at least) the crux of the issue.

What messaging system other than email allows for topic based discussion? I guess you could abuse groups to donsomething similar, but its not wuite the same.

The underlying one person to one person philosophy of messaging apps is infuriating for organised discussion over time. It makes finding info discussed harder too.

Does anyone have any suggestions for messaging apps that don't put person to person front and center but topic discussion like email?

(You might argue the last point i made there, but go and make two separately stored discussions with the same person on whatsapp or signal or wharever... I'll wait).

>Does anyone have any suggestions for messaging apps that don't put person to person front and center but topic discussion like email?

IRC, Riot (Matrix in general), Slack, Discord, Rocket.Chat. There are quite a few.

I'm partial to Matrix, personally - you can invite a few friends for a room, and naming that room/setting a topic are optional, so either use case is fairly natural.

Hmm, not really. All those apps fall into the trap of following a UX design where it's all about a group or person and the conversation within.

IRC is channels, Slack is channels, Riot seems to just basically be IRC, Discord is another take on the same genre.

None of them give you what email gives you.

With email there's not a person or group in sight in the UX, save for perhaps a 'from' entry in the thread list. It's all about info. I can start 100 conversations with the same person and have those threads organised into a timeline separately from each other. I can then also arrange them into arbitrary collections.

I can possibly achieve something sort of like this by abusing groups or channels in these other apps, but then what? I just get a sidebar full of the things - what do I do with them? Can I search them and the info within from a global panel? Can I organise them into folders? Copy them to other accounts with a simple drag and drop?

Email has quite a different focus than all those apps you mentioned which is probably why nothing has replaced it.

In consideration of the fact WhatApp is owned by a single company (facebook), which gets all the metadata, how is it federated?

By far the most important: A desktop client that works without a smart-phone.

Identity management that is not smart-phone/phone-number based.

Better UI for long form messages, including citing previous lines.

Better support for adding people to ongoing conversations.

UI for conversations per topic rather than per person.

Mailing lists, and the ability to filter them to different folders (or equivalent UI elements).

Functioning as a searchable database of documents I have received. (Important detail: Attachments aren't independent messages: They are attached to often long form messages that describe their content).

Basically, WhatsApp does a subset of what EMail does but dramatically better and encrypted. But that covers only half of my email usage at most.

> that covers only half of my email usage at most

Yes, I guess that is the way forward. Split email into a set of different applications. Maybe one of them will take over the rest at some point.

I'm a bit late to this, but check out keybase chat. You can sign up on desktop / mobile / whatever you like, and desktop users can even drag and drop to a folder on their computer to share files (with like a 250gb per person limit right now I think), so that gets you a lot of the functionality of email right there.

> Which is why a lot of us look at our email inboxes these days and notice that most of what's in there is automated transactional stuff, with occasional cold inbound introductions that quickly transition off into some better medium.

If e-mail was gone tomorrow, where do you think all those automated transactional stuff would go? It won't disappear; suddenly, every business you pass will try to add itself to your contact list on $secure_im_of_choice, and you'll have just about the same volume of spam as on e-mail, just as a condition of being able to do any kind of business on-line.

I've seen you as the top commenter on almost every topic of email security, pitching the same arguments.

There is significant demand for content-encrypted asynchronous messaging for all routine purposes. Chat apps do not provide the appropriate platform for real world communication of substance, and security is and must be sought by less dismissive developers than you.

Signal Protocol is designed for asynchronous messaging.

OK, so implement a Double-Ratchet protocol for email clients and call it a day. Don't say that no engineering is possible on this problem, as if that isn't a farcical statement.

The problem is that you can't do it. More precisely, you cannot get people to convert to your encryption scheme. And if you could do it, you could as well convert them to a better protocol altogether.

At least this is how I understand tptacek's argument.

Have you considered that there might be a reason why none of the proposed schemes to retrofit encryption onto email involve double-ratchet protocols, even though all sorts of people come up with new messaging apps that do use double-ratchets? I think it's because it's very painful to accomplish ratchets in store-and-forward email, where the message update frequency is often measured in minutes, not milliseconds.

At any rate: suppose you actually accomplished that. You've still addressed only one of the bullets in my list above. Why bother? If you can get people to adopt new software, get them to adopt Signal, WhatsApp, or Wire.

An individual server-to-server communication occurs in milliseconds, so the fact that messages do not arrive frequently is completely irrelevant. It's simply because Moxie -- someone likely to be immune to your kind of negativism -- has not seen fit to work on the problem, given that messaging with an asynchronous chat format fits the general trend of user adoption. Someday I suspect he'll come around on it, I hope.

An individual server-to-server communication happens in milliseconds, but these systems layer on top of existing email clients, which do not have a polling interval of milliseconds.

I wouldn't hold your breath on email crypto from Moxie.

I don't think you know how Signal or the underlying protocol works based on this comment, so I'll just leave the discussion there. Feel free to read the specification. It's quite comprehensible and well-written.

Send message to server. Wait for server to tell you if the list of device-id's is current; if not, re-send with the server's update. What part of that works well with a client that checks for new messages every 5 minutes?

> It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.

SMTP has the exact same mechanisms, as does IMAP. HTTPS does not protect data at rest, and it doesn't protect data from the service provider, it never promised to.

There is functionally no difference between the SMTP/IMAP and HTTPS security models.

You're confusing client-server secure transport with secure messaging, which is not at all the same thing. Yes: you can ensure a specific SMTP (or IMAP) client connection is encrypted with TLS. But email is store-and-forward. What you can't do is ensure that a given message is encrypted at every hop, let alone end-to-end, where only the sender and receiver can read it.

Obviously, that's the point of layering OpenPGP on top of email. But, like I said: that's opt-in, with plaintext as a default. We would never accept that design in a secure messenger system.

I disagree, while also agreeing that IMAPS/SMTP-with-TLS is a huge improvement.

The big difference between HTTPS and SMTP is that there's an implicit extra hop. I go to send you an email. I connect to my outgoing mail server over SMTP-with-TLS, and anyone monitoring my connection cannot see the content of the message. Awesome! Likewise, you retrieve the message using IMAPS, and anyone monitoring your connect cannot see the content. Great!

But in between, there's absolutely no guarantee that my email provider sent it to your email provider over SMTP-with-TLS. It could very well have traveled completely cleartext, at which point it was harvested and archived by the NSA, with neither of our email providers having handed it over to them.

> But in between, there's absolutely no guarantee that my email provider sent it to your email provider over SMTP-with-TLS.

Don't accept non-STARTTLS traffic. Google doesn't, you shouldn't have to either. STARTTLS is widely available, and simply needs to be configured. Encouraging everyone to configure STARTTLS correctly is the easiest win we'll have.

And I hope you don't take what I said to mean that IMAPS and SMTP over TLS are a proper message encryption system. I simply meant that HTTPS doesn't do anything right that IMAPS or SMTP over TLS don't also.

Clearly there needs to be a standard way of advertising, distributing, transitioning, and retiring keys for email addresses. It needs to be robust, in continuity with existing infrastructure (probably domainkeys signed), straightforward (maybe signed proof of sender keys in a header), and possible to delegate in a way which meets the requirements of mailing lists. It also needs to be robust against malicious MTAs who could otherwise silently spoof senders and misrepresent their keys (double signing?).

A system with these properties would also solve the problematic interactions between DMARC and mailing lists which prevent almost everyone from deploying an appropriate DMARC policy today. If somebody is working on this I'd like to know about it.

> It needs to be robust, in continuity with existing infrastructure (probably domainkeys signed), straightforward (maybe signed proof of sender keys in a header)

We get fairly close here if we can get providers to DKIM-sign Autocrypt headers, like Posteo already does.

E-Mail has a lot of baggage though, and we don't expect to get everything done overnight. Legacy is important, and development resources in this area are realistically very limited. Still, we feel like we have a reasonable start.

> It also needs to be robust against malicious MTAs who could otherwise silently spoof senders and misrepresent their keys (double signing?).

I think the best we can do here is to make providers sign keys during transit, and increase attacker risk by allowing users to verify their communications at any point.

Google won't accept inbound mail (from an MTA, not an MUA) that doesn't do STARTTLS? If that's true, I'm both impressed (at their resolve to make the Internet a better place), and concerned that messages from old ISPs that haven't upgraded in a decade won't ever reach my GMail account.

Google does accept it. To do otherwise would violate the RFCs.

They won't accept an e-mail from a user ("submission") without STARTTLS, however. An MUA must negotiate the encrypted channel before even being allowed to authenticate. AFAIK, this is pretty much a universal requirement on the {IMAP4,POP3}-over-TLS ports (993,995/TCP) -- it definitely is on the mail servers I run.

Right, but that was my entire point. Just because both users/MUAs are using STARTTLS has no bearing on whether the message is sent in the clear across the internet from MTA to MTA. That's where STARTTLS is worse than HTTPS. With an HTTPS request, there's a pretty good chance that the messages are getting from source-to-destination without ever traversing the Internet in cleartext (modulo MitM with forged certificates)

Sorry, you misinterpreted my reply. I agree with you completely. I replied mostly to point out that microcolonel's statement that

> Don't accept non-STARTTLS traffic. Google doesn't, ...

is incorrect -- as you doubted:

> If that's true, I'm both impressed ...

Oh! Apologies, didn't notice that you weren't the parent. Cheers :)

I don't think we need serious secure messengers, because we mostly don't need to send secure messages.

Email is "mail on the internet". Mail isn't secure. We use mail everywhere for everything. Occasionally there can be some security problems with conventional mail, but they're fairly rare and we tend to get on with life. And if you need to send a secret via the mail, you can do what the military has been doing for 2,000 years and encrypt your message contents. So I agree, we should stop freaking out about mail.

But we need a secure messaging system? We didn't seem to need it for the post. For the average hacker it's nearly impossible to break into modern messaging systems, centralized and encrypted as they are today. And a lot of us live in free societies where repressive regimes don't legally get to spy on our messages.

Now, this will change in 20 years when China starts spreading its form of Communism around the world similar to how we spread Democracy, as more nations will start adopting internet censorship. But as we've seen with a lot of censorship-circumvention technology, the authorities are pretty successful at blocking or banning the means, and providing state-sponsored replacements when they can't effectively do that.

If you want someone to deliver you a secret today, nearly any messaging service will do. If you don't want to rely on a particular central messaging service, you have to go back to PKI or public-key crypto, which nobody wants to do. Basically, we have "good enough" solutions today, and we have better solutions that people can use if they have to. So I don't think a new secure messaging system is warranted.

You might think we mostly don't need to send secure messages, but remember, Pervasive Monitoring Is an Attack (BCP-188):

https://www.rfc-editor.org/bcp/bcp188.txt

First of all, most messaging platforms today are encrypted, so that rfc wouldn't really apply except to monitoring by the company providing the service, and that's the price you pay for "free stuff on the internet".

Second, almost all the "attackers" are nation-states and your ISP. If it's illegal to read your mail, it should be illegal to read your email (simple regulatory fix). That just leaves spy organizations, and nobody but computer geeks and privacy nutjobs cares about that.

First of all, some messaging platforms today are End-to-End encrypted, which is in keeping with the thinking behind that RFC. Given that such models of communication are available as "free stuff on the internet", we shouldn't expect anything less than that from now on (and we should be improving email protocols and implementations to offer at least an equivalent level of privacy).

Second, your "simple regulatory fix" is proving to be not so simple in many nation-states, even ones which claim to be democracies, and I don't think we should ignore people's need for privacy and security while we wait for government policy to fix itself. Indeed, if we do not strengthen the level of privacy and security that people enjoy, the job of fixing government policy becomes that much harder.

To give some examples of recent attacks that even non-technical users need to think about (or at least be protected from), consider these:

https://www.eff.org/deeplinks/2014/11/verizon-x-uidh

https://www.washingtonpost.com/news/the-switch/wp/2015/03/30...

> Most email clients are searchable-archive-by-default.

That's a feature, not a bug. A "secure" messenger I can't search my entire locally stored archive of can't replace my usage of email.

I agree with the premise that something that works like email but secure might do better to not start with email as a baseline. But that doesn't mean it should throw out the most critical properties of email in the process.

> Everything that makes email effective in the real world makes it inhospitable to secure messaging. We should stop trying to push this particular boulder up this particular mountain and instead just get people to adopt serious secure messengers.

We also need to build serious secure messengers that are "effective in the real world" in the same way that email is. That doesn't mean they have to build on email.

I agree with you on everything here except for your "don't use email" point in the followups. For 99+% of people, being able to recover your archive when you forget your password or lose your device is more valuable than being secure against a state-level adversary.

I think the security debate around email suffers from an over-supply of confidentiality absolutists, in which both integrity and availability take the back seat to defense (or the theatre of defense) against a very narrow set of attacks.

Indeed just getting most senders and servers to use TLS would be a good start.

That said, lots of businesses deal with sophisticated attackers who are trying to steal trade secrets, patents in progress, etc. Sometimes these attackers are state sponsored too (I would definitely suspect China, US and Russia for this kind of crimes).

That comes down to risk analysis there. These businesses should probably be running their own mail infrastructure and doing exfiltration scanning of all outbound messages (which needs them to be in the clear at that point, or at least decryptable by the gateway box).

Those sorts of businesses also benefit massively from being able to scan incoming messages for spear phishing and viruses BEFORE they get delivered to the end-user device, something which isn't possible if the business firewall can't introspect the messages which are coming through.

I think you're actually making my confidentiality absolutist point for me here. Businesses benefit from being able to analyse mail flow across all their employees and spam/virus/fraud scan incoming messages.

You assume that secrets circulate only within organizations and that no external parties (contractors, business partners, investors) are involved.

Outbound filters aren't smart enough to detect escaping secrets. And inbound malware scanner can just as well run on the target device or it can be invoked from the device for suspicious attachments.

Most email on the Internet today does use TLS at present. Google's Safer Email transparency report includes metrics for the rates of inbound and outbound email encryption at Gmail, and both are about 90%.

These days all major providers and software support TLS and will employ it by default. (There are some holdouts though, just like for HTTP.)

[1] https://transparencyreport.google.com/safer-email/overview

Secure cryptographic end-to-end protocols have a fun way of making it harder to actually run restricted, secure networks, because it makes enforcing content-based policies rather interesting.

...and if you are going to ignore what tptacek says and try it anyway, I think it can be done a little better than the submitted product (although I only skimmed their site so I might be misunderstanding a bit).

I worked at a company that had a go at end to end email encryption around 2001. The basic idea of the submitted system looks quite similar to what we did--piggyback on top of existing email clients and their messages.

However, we did not want to require modifying the MUAs or installing plug-ins or extensions or whatever a given MUA supported for that kind of stuff. We needed to support pretty much ever MUA on Windows, and writing plug-ins for each would have been impractical (and I don't think they all supported that).

So instead of hooking in directly in the MUA, our first approach would have the user configure their MUA to use a proxy, and our software installed a local email proxy. It's been a long time so I may be mixing up some projects, but I think we later did a version where we played around with intercepting things by hooking Winsock, and another version where we used the Service Provider Interface to get in there [1].

Anyway, the first time you used the proxy it would generate a key pair for you, and then on your outgoing mail would put your public key in a header. If incoming mail had someone else's public key in the header it would import that into your keyring.

You could set it to sign your outgoing mail. I don't remember what options we have for protecting your private key. My guess is that they were weak, because as is usual when the marketing folks have too much influence, convenience trumps security.

Incoming signed mail would have the signature checked by the proxy, and it would annotate the message somehow so that the result would be visible in your email client. I don't remember if we added something to the subject, or added a status header, or added something to the body.

Encryption was similar. If the proxy saw that you were sending to some for whom it had a public key, you could set it to encrypt using that public key. (By which I mean encrypt with a symmetric cipher, and use RSA to encrypt the key...I believe we were simply using GPG).

As with signing, convenience won if it came into conflict with security, I believe (and over my objection, if I recall correctly).

From a user point of view this actually worked pretty well. As I said, we rejected the plug-in approach because it was impractical to write and maintain plug-ins for each client. However, it was practical for all the major ones (and many less major ones) to poke around in the registry or find their config file, and figure out how to programmatically edit those to change proxy settings, thus allowing our installer to find and configure all your email clients. So from the user point of view, you just installed our program, and started using email normally. After a mail and answer between two people who both used it, subsequent messages between them would be encrypted and signed.

Of course there was still the issue that this just told you that the subsequent messages were to someone who had access to the keys of the person you initially exchanged messages with at that address--it doesn't verity that they are really who you think they are. I don't remember if we had a way to go outside the system to verify someone's public key and tell the system you have done so.

As I write this, I'm now starting to think it wasn't just a simple proxy that just passed requests through, occasionally diddling the headers and the body. I think it was actually an IMAP server that stored messages itself. I think that was so it could keep copies of the encrypted incoming messages itself, and then the email clients could be configured not to store local copies of mail. That way the mail would only be decrypted when you are actually reading it in the email client.

Anyway, I think that this could have been made quite reasonable at the time (around 2001). Email has gotten quite a bit more complicated since then. Most people then only used their email from a single computer. Now they use it from 2 or 3 devices, or more, often each running a different operating system. There's no good place controlled by the user that you can put the proxy that is accessible to all of their clients, and so you really need to provide this as a service that includes a server to handle the email...but then how do you let people keep using their existing email address? I supposed you could do an ugly hack like configuring their email clients to all forward incoming mail to the service's server, which decrypts it and sends it back...yuck.

At this point it seems clear that you should just use some dedicated secure messaging app for your secrets, and keep email like it is now, as tptacek said.

In short, I think this is an idea whose time has come...and gone.

[1] I may be mixing up different projects because we had this completely insane contract at the time with one of the biggest distributors of Windows utility software in Japan to provide him with something like 12 new products a year, and new versions of 6 prior products a year, which led to a couple years where everything is largely a blur of projects that mix together in my mind.

I don't see the business world adopting "serious" secure messengers anytime soon. People don't want to send business stuff over WhatsApp, so we'll have to "bother" with email a couple decades longer.

But I really hate that I can't encrypt business communication, like invoices or contracts, without resorting to encrypted.zip. What's wrong with fixing that situation?

> but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.

There is a draft standard [1] for strict transport security. I'm not sure of its current status though.

> Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simply content. They're sent in plaintext.

Nothing sent during the data phase of the SMTP transaction has to strictly be unencrypted. There's nothing preventing the client from encrypting both the headers and body of the message. But that doesn't prevent the MTA itself from adding uncrypted headers to the message after the client sends the CRLF.CRLF sequence to end the data phase.

> Most email users get their email from a website. Unless you make them install something on all their computers

I'm not sure how many users still use a dedicated email client, but I'm sure that there are many who use clients like Outlook, Apple Mail, Thunderbird, amongst others. Anyone who wants to encrypt their email needs to know they need to use a client on their machine that handles the encryption/decryption steps for them (or that they need to do it themselves.

[1] https://www.infoworld.com/article/3046850/security/google-mi...

That's strict transport security between hops. There's no proposal on the table for end-to-end encryption, or even (so far as I know) for a header that would signal that a message be dropped before it's sent over an unencrypted channel --- right now, servers simply agree between themselves to enforce transport security, with no input from messages.

Realistically, how many hops are we talking? The dns mx record points to a server that handles mail for a user - anything beyond that point is that domains problem to secure - and it's relatively easy to do so. (The exception being aliased/forwarded addresses - but that's handled on the server side - and could also be set to force ssl/tls).

The sender needs a smtp server, usually "their own", and usually (today) supports tls/ssl.

Now the sender_smtp-receiver_smtp needs to enforce encryption. I really think we're at a point where forcing ssl on incoming mail would a) not lose any legitimate email, b) maybe block some spam.

Then, remove support for connecting to mail over unencrypted pop/imap/smtp for mail clients (probably except for localcast, to not break "known secure transport" like an ssh/vpn tunnel).

Since Gmail, outlook.com have effectively broken easy mail federation (oh, look a bad man had your ip a year ago, no mail for you, and no, we won't bounce it with an error, just silently drop it/file it as spam) - we have an oppsto be a bit aggressive in phasing out old rfcs that allow unencrypted smtp/imap/pop over untrusted networks.

I'll happily concede that patching transport security doesn't make email end-to-end secure. Then again, I'm not sure the Web is any better: ssl is hop-by-hop, clients keep a plain text cache on disk, along with a log of meta-data (and servers tend to log a lot of plain text meta-data too), client certificates are being phased out for http2...

Wrapping messages in s/mime or gpg actually looks pretty good by comparison.

Maybe what we need is a suggestion that if you email user+secure@example.com rather than user@ - only email encrypted to User@example.com (with user+secure@ as alt identity...) will get through?

Then muas could check to see if there's a gpg key for user+secure@, given mailto user@, in the directory - and transparently Encrypt by default?

It doesn't make sense to talk about whether HTTPS is end-to-end encrypted. Sometimes it is, sometimes it isn't. If you're exchange secrets directly with a web application that doesn't leave the application's secured deployment environment, TLS is all you need. But if you're exchanging secrets with another person using a server as a mediator --- as is the case with web chat and web email systems --- then it's not.

I don't know why we'd bother with fussy contraptions involving special email addresses that nobody knows about, let alone uses. We have secure messaging systems today, systems billions of people already use, they're designed from the ground up to handle these problems, and so they're much better at security than any email system we can even reasonably come up with might be.

Why are we wasting time trying to make people feel safer emailing secrets? We should get them to stop doing that at all.

It's my understanding that most of these secure messaging system relay via servers speaking https - and their distinctive feature is that the clients are distributed as self-contained apps, that wrap the complexity, and label "signal-protocol over https rpc" as just "signal" (similar for WhatsApp etc).

Why is it hopeless to do the same for email? Take a sane protocol subset, add a convention protocol for encryption, and ship it as "secure email"?

It is a tautology that a "secure mail app" that allows "traditional email interop" cannot make strong privacy guarantees, just like when using WhatsApp you give up federation and networking-as-a-utility (you're completely beholden to a provider that you don't even have a proper contract with, let alone the opportunity to seamlessly move providers / self-host / federate while maintaining global addressing and data portability).

I think that's part of the disconnect in the discussion - wrapping a sane protocol selection in an opaque app along with a saas/paas silo that limits addressing, routing and federation is OK for some arbitrary subset of not-by-themselves secure protocols, but any suggestion that reusing elements of email is dismissed as "can't be done" (or "can't be done, because webmail", while "can't be done because messenger.com" seems absent).

We've already done meta-data wrapping for email, with one, perhaps flawed approach:

https://en.m.wikipedia.org/wiki/Mixmaster_anonymous_remailer

Secure messengers might use TLS (though probably not HTTPS) to connect to servers, but messages themselves are independently encrypted: they don't rely on TLS for message encryption.

Right. And gpg messages are also independently encrypted, although subject isn't scrubbed by default, and some routing information leaks by default (although eg Mixmasters exist as one approach for mitigating the latter to a certain extent. All system will need to have some routing information. Come to think of it, gpg+usenet might be "better" example of "old tech" secure messaging).

Ed: i suppose the question.becomes if new systems rely on tls to help obscure meta-data or not; like what mail+gpg does.

Yeah, but we need email 2.0, encrypted by default. Maybe not call it user+secure@example.com but something like user@@example.com

Sure, the reasoning for username+secure is that most mail servers are set up to forward that, so if I send a pgp encrypted mail to user+secure@example.com today, user@example.com will get it, and can read it using regular mail+pgp setup.

The server could then be augmented to drop unencrypted mail to "+secure" - and mail user agents could handle pgp keys and "+secure" addresses especially.

For example split mail delivered to user@ and user+secure@ in a "insecure/postcard/public" view and a "private/personal/letter-in-envelope" view.

> Most email users get their email from a website.

I'd argue thats not the case. Business users are likely still using outlook/etc. Personal users are likely using their smart phone for email.

Also by what standard is pgp "the most popular". Its popular with technical people sure, but there is fuck all support in commercial mail clients. S/mime is supported, and due to ca roots, doesnt require you keep using the sams private key - you could use a new cert every 3 months ala LE if you wanted

Thunderbird and apple mail are both very popular clients that support PGP via plugins.

I use the pgp plugin for apple mail on my mac, but I wouldn't want to rely on it for anything business critical.

It's usually months after a macos/mail.app update before the plugin works again.

Theres no equivalent option for iOS. There are alternative solutions but nothing as seamless.

S/MIME is supported out of the box. For bonus ease of setup, I can install the current private key + cert pairs I need with a single provisioning profile.

"Unpopular but probably very true fact: ..."

Another unpopular but very true fact:

"Email", the technology, not the business, can be defined as party A depositing an RFC811 formatted message on the computer of party B. Email requires only a reachable IP address.

This definition of email can be implemented withut using third party intermediary SMTP servers. Sender and reciever SMTP servers can communicate directly, without so-called "store and forward". I conducted an experiment of "peer-to-peer" email: both sender and receiver are on a Layer 2 overlay, i.e., /dev/tap0 with private IP address, each running their own smtp server bound to tap0. qmail was used, it accepts IP addresses; no ICANN domainnames were needed but private DNS names were also tested. All traffic going through tap0 was encrypted. (Note: I did not use OpenVPN.) It worked as expected. The Layer 2 approach I used would be limited as to the size of networks but would probably accomodate the size of a persons cricle of friends, family and colleagues; addtionally small virtual LAN networks can be bridged to create larger internetowrks. It would probably work with encryption at Layer 3 as well, without such limitations. Maybe people have/will do this with Wireguard.

Whether or not this works for the email "business" is irrelevant. Whether or not this is practical for anyones use case is also irrelevant to this comment. The question is whether email can be encrypted. For me, the experiment proves it can, in at least one way.

Of course, once party A and party B have an end-to-end connection, e.g., over a "virtual LAN" over the internet, then there are many more interesting possibilities for communication than just "email".

Email has evolved in the way it is implemented, and IMO it can evolve further. If I recall correctly from reading old RFCs, I believe the original "email" was actually done via FTP. One deposited mail by appending to a file on the recipients computer. Of course in those days that computer was timeshared by many recipients because computers were too expensive for individual recipients to own. This is no longer true today. Computers are affordable for all recipients. (Yet, with respect to email, recipient still share computers. These are run by "email providers".)

> Email is itself archaic,

Very true and yet its the only messaging with wide adoption that is federated. There are so many better ways to communicate now days all of them locking you to a specific vendor. So whether it's archaic or not there isn't really any alternative :)

SMTP belongs in the trash, sure.

Whatever happened to the Dark Mail Alliance working on replacing it?

https://en.wikipedia.org/wiki/Dark_Mail_Alliance

"email can't practicably be made secure, and people should stop trying."

It's already been done as I've told you before: they're called encrypting proxies and mail guards [1][2]. A few ran on OS's that passed NSA pentesting while all the other stuff failed. So, they can be done to much higher security than most things you use or recommended for risk mitigation. There's FOSS tooling available to build modern versions in medium or high security should anyone want to try. Tooling is better than ever for plugging leaks or knocking out code injections without having teams of pros doing all the work. There's also companies selling modern versions for businesses wanting some protection for legacy usage, except not on the secure OS's anymore.

So, you're just ignoring prior work again like you did when you dismissed separation kernels because you didn't know high-assurance, security field designed secure, browser architectures or integrated existing ones. Being archaic, secure email does have issues to solve with residual risks that can happen with new solution integrating with legacy tech. Best it will get with current setups is medium-assurance like with most internet protocols, common platforms, and so on. Still useful to build security tech for it given how pervasive email is with too much inertia to eliminate if we're about protection of lots of users and critical activity.

"Most email users get their email from a website. " "And where by "agony" we mean "innocent people being put at risk"."

The other thing I noticed about this post is a double standard your pushing. When I talked secure OS's, you argued they shouldn't be taken seriously unless they have a browser. The implication was that browsers were a pervasively-used tool (like email) that we should (a) support since in demand and (b) secure to be responsible. We had to do what's practical supporting them even though they're the source of most compromises. Now, when talking email, you're saying people should ditch it for totally-different mediums without the strengths of email (i.e. less practical for their needs). That we should not be practical since it would be irresponsible to push a tech or app with high-compromise potential that could put innocent people at risk. That is, putting people at risk just like browsers do versus using secure, simple, native apps (esp memory-safe) or less-sophisticated formats for documents.

Maybe you changed your mind about browsers with you now recommending whatever are the Signal's of document exchange or web-app alternatives. Otherwise, you've done for one medium what you say shouldn't be done for the other. Interestingly enough, those who listen to you that avoid email for messenging apps, but who use browsers, might have their messages stolen anyway from that point on when the browser gets hacked. Among other problems following a hack.

"We should stop trying to push this particular boulder up this particular mountain and instead just get people to adopt serious secure messengers."

Again. Let me rephrase to illustrate: we should stop trying to push secure versions of (insanely-popular, legacy tech not going anywhere) to get people to quit using it in favor of secure alternatives that don't have benefits that led them to the other one in the first place. I can think of email, browsers, online storage for files, desktop OS's, ISA's, and so on that inherently have risks that we can't fully eliminate. It's insanely impractical to get people off this stuff for clean-slate, secure alternatives. You're making an exception for email expecting people to move mountains changing all the inertia.

We do agree that security pro's should get people off email where we can where their requirements don't truly dictate email. We still need secure email, though, for those that won't or can't stop using it. That's only if we're about protecting innocent people, business activities, government practices, and so on who are all over email.

[1] An early one https://cryptosmith.files.wordpress.com/2014/10/mailguard.pd...

[2] General concept with newer ones https://en.wikipedia.org/wiki/Guard_(information_security)

Not sure you're still right in 2018. Where I live, non-tech people have more or less stopped using email for non-work stuff in favor of WhatsApp. Facebook gets all the metadata, but you would probably argue that this is much better than an open standard like e-mail.

E-Mails are mostly used for work-related information exchange. Those emails are usually sent from a PC in some corporate setting. The IT departments could enforce the use of encryption but nobody cares -- maybe also because management isn't aware of how email works and doesn't care until it is forced to.

Unfortunately, Signal is not decentralized or federated (for good reasons[1]). Email is. This is an important feature for those of us who worry about the growing centralization of the web, as well as the very many users who still mainly use email for communication. When you leave a job, you may not keep your email address, but at least you can still communicate with people across organizational boundaries.

Anyway, even if email security cannot be perfect, I agree with the sentiment behind RFC 7435[2] - some protection is better than nothing.

If anything, I feel that they didn't go far enough in this compromise. Most people interact with their email through the provider's webmail client. Autocrypt is fundamentally incompatible with this[3]. This means that it will really not be useful for the majority of users.

1: https://signal.org/blog/the-ecosystem-is-moving/

2: https://tools.ietf.org/html/rfc7435.html

3: https://autocrypt.org/level1.html#requirements-on-mua-e-mail...

Webmail is indeed a very tricky one. Mailvelope does a fairly good job, but without some provider support that allows setting/reading headers and sending custom mime parts, there is sadly no good way to solve this problem.

> Anyway, even if email security cannot be perfect, I agree with the sentiment behind RFC 7435[2] - some protection is better than nothing.

Opportunistic encryption (or any kind of negotiable security) is prone to downgrades by a MITM. Either both sides require strong security, or you must assume lowest common denominator.

While I have your attention, please do yourself a favor and pin some strong, modern ciphers for your SSH client: https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern

To a pretty good first approximation zero percent of messaging users care about federation.

It's clear to me why "don't bother encrypting email" upsets nerds on message boards. But if you're going to trade getting the maximum number of messages safely encrypted for a deeply uncertain future in which most email is somehow reliably encrypted, you have priorities other than end-user safety --- and, I would argue (but do accept that I can't do so conclusively) priorities other than security engineering.

This argument is always a mess. I think a lot of the problem stems from not having a clear definition of what we mean when we say "email". Some of these complaints seem to be about SMTP, some are about client programs, and some are about PGP.

Your individual concerns are all valid, but that doesn't mean they come together to make a compelling argument that email will always be horribly insecure. Heck, you could probably take most of the points in the parent comment, change a few words, and have a pretty solid argument to take back to 2008 and convince everyone that mobile device messaging will never be secure.

There's nothing inherent to the concept of "email" that says we have to use any of these individual flawed components, or that we have to use them together in exactly the same way as we're doing now. For example - What's to stop somebody from taking the Signal code and hacking up support for a mail client that uses Signal with SMTP as the transport?

Look at X3DH, Double Ratchet, and Sesame and sketch for me a comparably secure system that uses SMTP as the transport and that doesn't reduce SMTP to a tunneling mechanism for an entirely different protocol.

Let's accept all this as true. (I've got some quibbles, but agree in general form.)

1. What's the alternative look like?

2. How do we get there from here?

If you've a prepared piece on this (or someone else's that you largely agree with), that would be great to point at.

If you don't, I'd very much like to see something.

I've been trying to keep vaguely on top of email and messaging protocols and failing massively. My own view is that SMTP email probably is done for, though there may be some Good Bits to salvage, and most definitely some Hard Lessons to retain.

I predict autocrypt will get basically zero adoption because no mail clients with significant user bases will bother with it, and the rest are web apps anyway.

It would be nice if there were a signal client that looked like an email client, organizing messages by subject rather than conversation partner.

Not sure why anyone doubts or is upset by this. In my field, health professionals send all sorts of critical confidential information in email, and never delete any of it. For each person where email has good enough security, or can be made as such, there are 10 where it will never be remotely adequate in real world usage.

IM won't replace e-mail due to two important things you seem to be neglecting (for a long time :) ). They are:

* human psychology and ways of working

* lack of features on IM (and this problem is bigger than implementing crypto in e-mail).

Let me describe them more, starting with humans:

* we love to separate things in our minds, like work/home linkedin/facebook profiles that will never merge, no matter how much money fb will pour into fbworks or others.

* we assign e-mail, an aspect of 'longer asynchronous communication'. We desire this 'asynchronous' aspect, allowing replying us with a delay. We demand that a separate (sic!) tool with such characteristic (and publicly agreed typical use) exists

* we need communication tool for longer (like this or yours post) exchanges, where MULTIPLE people can participate. We need to able to put into one message 10..20 minutes of work. And no, we will not be publishing and exchaning academic papers (read attachments/separate documents) for such discussion to happen.

* it can't be tied to instant/short comm tool.

_______

Features:

* we need (must) to have a searchable archive of this communication tool, instantly available, surviving device changes (telegram and signal are out), and multiple years to store

* this tool must be connected to publicly available namescheme of internet: domain names - no IM are, they create they own space. This is ultra crucial: I must be able to send and receive information to a participant who I know only a domain. Like for examples yours: youagain@latacora.com

* I need to be able to talk with multiple people, knowing who they are (domains), and @Immuppet1980 or @894984320123 is not, while tptacek@latacora.com is

* we need to to have multiple addresses all being accessed with relatively small number of clients (read 2). Welcome to the IM hell, when if you're 40 and have friends from around world you need to ahve: signal, telegram, fb, whatsap, sms, ghangout, alo, and I'm not even started with asian tools! This sucks.

So no, while I share your despise to current crypto-email state, the proper way is to try to secure e-mail, not to get rid of it. Incrementally, getting rid, one by one all bad things of it. There is no bing bang approach.

> and instead just get people to adopt serious secure messengers

And here is the main issue, they don't substitute email:

- Async

- Allowing long form text/attachments

- User friendly address (phone numbers are not very easy - we just got accustomed)

- Threaded and archivable conversations

> Unpopular but very probably true fact [...]

That's not a fact. That's a conclusion based on the premises you put forth. You should put the conclusion on the bottom of your post. Now it is akin to a forecast or fortune-telling. There's no need to resort to such strong language in an otherwise decent post. Your premises don't need it, and your argument doesn't need it either. If you worded your post slightly less bifurcating it would've been an excellent post without sparkling the controversial discussion.

As for your premises,

> Email leaks metadata. [...]

Agreed, but

> stuff like subject lines are simply content.

Its optional content because if sender wants it to be gibberish or deceiving, that's possible.

> * Most email users get their email from a website. Unless you make them install something on all their computers

That's a matter of RFCs and implementing the new technology in client and server. If we follow your reasoning, we'd still be sitting in the previous century in old standards "because the poor users must upgrade their software."

For the other premises (such as for example "It's default-plaintext."), can you demonstrate it is impossible to fix these issues? Because I don't see that being taken into account. What I see is: "let us break backwards compatibility and switch to this here which is better" but without authority to do that for a significant amount of users we're left with the practical situation of a chicken-egg problem of a defacto standard. And could you actually directly quote from the article what and why is not feasible instead of a general dismissal? The latter feels like a rant the former feels like an in depth discussion. Someone could've written a rant like that about DNS (because IPv4), or about TCP because BGP, but what we need is solutions. IPv4 is an interesting discussion because of IPv6. Its a recent, significant example of the chicken-egg problem of an inferior standard, backwards compatibility, and how to make the switch.

Intra-organizational email is pretty secure. Like where I work, we’re all on gmail with client carts.

How using Gmail could be called secure? According to Snowden docs Google is cooperating with N/S/A. So all your data is collected and stored for future analysis when needed. If you consider this to be "secure" then the whole discussion on security is pointless.

I'm not sure what the problem you are having is here. Transport can be secure with TLS. Content can be secured with smime or even archaic and ancient pgp. Leaky metadata is a problem with every protocol that can be routed. Oh, and email is one of the few things on the internet that universally works...

>Unpopular but very probably true fact

Meta nit: prefacing an argument with this is irritating and is essentially a dressed up "I'll probably get downvoted for saying this."

Don't tempt me to not like a statement ahead of time, just make the damn statement!

You're right.

Email can be made secure, it's just that by default it's insecure and there isn't a Google/Mozilla/Microsoft/Apple conglomerate to penalize SMTP servers by showing "Insecure" in an email display/etc.

* Most mail transport agents can require connections to use TLS, but nobody does because they're afraid of denying incoming messages and because it can be difficult to install a certificate for an MTA, so smaller providers just don't. There should be a LetsEncrypt for mail servers and by default the various package managers and distributions should not install a mail agent that allows non-TLS connections.

* It is possible to store mail messages encrypted at rest, but only by using an encrypted filesystem-- I'm not aware of any MTA that will do this itself. Obviously that needs to change.

* Providers can force TLS connections for IMAP. This is surprisingly easier these days given that most end user mail clients will auto-negotiate these connections.

There's your E2E encryption. This doesn't get you encryption on the final destination, but that's a separate issue.

For the nth time on this thread: TLS does not provide end-to-end encryption for email. End-to-end encryption means you can read your mail, and the person who receives your email can read it, and no system in between can ever see the plaintext.

Gah, the thing I truly hate about this website is that it doesn't offer me an answer to the most important question: But what does it do?

I have to scroll down to see the content in the "What is Autocrypt" section. The content was two sentences long and I still didn't understand what does it do (I wondered what's an "email program" in this context). Since there was no additional text to help me out on the homepage, I had to look further.

FAQ page was too technical for such an explanation, implementation status page gave me some genuine idea that this is something related to other OpenPGP products instead of a new OpenPGP product. The third page I tried opening was the "test it" page, which led me to basically nothing out of any use.

And this is not an isolated case, this is more of a rule for project websites. Seriously, figure out a layman term to explain whatever you're representing and slap it on top of your homepage. Nobody cares if you're decentralized or an open standard until we know what is it. "Convenient End-to-End Encryption for E-Mail" made me believe it was a separate OpenPGP implementation, not a set of guidelines.

Just one sentence like "a set of guidelines that make email encryption easier" would make me want to find out more. This way, by the time I found that out, I have already decided to write this out of rage instead of finding out more.

So, here's a plea to the authors of this website and every other project website: Please, tell me what your project does right at the top of your homepage and do not make me chase an answer to that question.

Note taken. Making a website for a tech spec is surprisingly hard after looking at it for so long :(

https://github.com/autocrypt/autocrypt/pull/328

The site could benefit from a to-the-point explanation that doesn't assume prior experience with PGP based mail. I can't point less technical users to this.

Does this work if one uses multiple mail clients (fx. notebook, desktop, and smartphone)?

Since it requires client support, it doesn't seem an option currently on, say, an iPhone.

Indeed, we are not at a stage yet where pointing "less technical users" to our website is very useful, since the main take away for those people is "stay tuned".

We hope to be able to change this as implementations progress.

To save some hunting around, here is the description of what is being proposed here:

* https://autocrypt.org/examples.html

Basically you include your public key in a "Autocrypt:" header line added to all messages you send out. Then encryption transparently happens.

So we give up some protection against MITM attacks but get protection against passive surveillance for people who are not willing or able to participate in a web of trust. All and all a good idea. Because this works with standard OpenPGP messages it would be good if we could tell what level of protection we were getting when we view a message.

How is this better than signing outgoing email, and default to encrypt to senders who sign their mail?

A signature does not give you a public key. You actually need the pub key to verify the signature.

I think one could still ask why you couldn't just use a mime section for the public key in the same way that signatures are often attached.

The implied missing steps are a)publish key to keyserver network, and b) get fingerprint from signature and look up key on keyserver network.

Bundling public key with every mail "feels" a bit heavy handed - given the key server infrastructure that already exist. (and special-casing "mail to new receiver" seems cumbersome. At least considering you'd probably want to sign all outgoing mail anyway[1]).

[1] Ok, maybe not your bomb threats if they're designed to be anonymous - but that's getting into one of the other issues with pgp - non-repudiation.

Here is a description how it works: https://posteo.de/en/blog/new-easy-email-encryption-with-aut...

>>The manual exchange and management of keys – which users often perceive as complicated – is becoming superfluous: Prior to the first encrypted communication, a regular empty email (without content) is sent. With this, the key is transferred in the background. Henceforth, messages can be encrypted automatically.

doesn't sound like they solved the key exchange problem. they merely changed it to trust on first use.

Which is a common compromise and frankly more useful than the web-of-trust model, as long as users understand the limitation and verify once offline.

It's still unclear to me how this works if you use more than one email client.

This seems like a good use case for keybase.io. They've implemented their own proof of concept messaging system, but I have yet to see any third party integrate with the service.

keybase.io is another centralized third party which, like Signal, we should be trying to move away from rather than becoming more dependent on. By relying on the DNS (which is already trusted to make email, keybase.io, and Signal work), every service provider can be in control of the keys they are publishing.

Also, keybase.io, being centralized, isn't as auditable as the DNS, but admittedly there is work being done on both DNSSEC transparency:

http://blog.huque.com/2014/07/dnssec-key-transparency.html

and keybase.io publishing to the bitcoin blockchain:

https://keybase.io/docs/server_security/merkle_root_in_bitco...

I'd say that it's only quasi centralized. At its core, keybase is a directory of signed statements posted on social media. Where space permits, these statements include the person's public key. Verifications can be checked directly on Facebook, Twitter, etc. without using keybase, somewhat decentralizing the service. As you mentioned, writing to blockchain pulls keybase further out of the equation.

They're more of a facilitator for other applications -- Signal is a packaged application itself.

There are complementary technologies which largely address the key exchange problem, such as RFC-7929:

https://tools.ietf.org/html/rfc7929

This is already supported by email providers like Posteo since 2015:

https://posteo.de/en/blog/new-posteo-public-key-directory

They also recently added support for Autocrypt itself, as linked above.

And that still defends against the biggest howler with email, that in raw form it is a post card, not a enveloped letter.

The issue if trusting that the sender is who is being claimed is a very different issue, and one that i don't think anyone had solved yet beyond cumbersome exchange procedures (possibly involving locked suitcases).

Pretty off topic, but: I've been working on signed web applications: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap.... If anyone working on a web-based email client wants to take a shot at making it completely secure (against the web app's server), shoot me an email :) in profile.

Who is the team or company behind this offering?

Developers from various open-source email clients. It's a protocol, not a product.

https://autocrypt.org/contact.html

Metadata is more important than content. Metadata is surveillance. There is no way to hide metadata with computers. The only way to get around this is through anonymity. You put the info out there, but it can't be correlated to you by someone else except your intended recipient. This is approaching impossible even with the best, security-minded infosec professional. The safeguards you need to employ are very extraordinary. One slip-up, UR-FCK'ed.

OPSEC is not retroactive.

Tackling header privacy is harder in an existing platform. Memoryhole ( https://github.com/autocrypt/memoryhole ) has some ideas but it's some way off implementation right now.

Send the link to your boss and ask his opinion

Say your company needs a new vehicle with specific safety features while still being convenient. When you find the vehicle that meets the requirements do you just plop the manual on your managers desk and ask for an opinion?

Reply on news.ycombinator.com