Hacker News Reader

Comment by jwr | Hacker News Reader

> the world at large dismissed OpenPGP encryption on mail as pointless

This is quite amazing, if you think about it. I'm not one to promote conspiracy theories, but if you look at how we horribly botched all implementations of E-mail encryption over the years (that includes lack of development, terrible UI, delays, bizarre and unimplementable in practice standards like S/MIME), it is quite an impressive story.

Meanwhile, the HTTP world mostly got things done, and instant messaging is in a pretty good shape (although I'm still amazed that so many people are willing to sync their entire phone book to Facebook for advertising purposes without a second thought).

View on HN

I don't think they were horribly botched. It's simply a very hard problem to tackle, much harder than, say, end-to-end encryption over HTTP (which is of course HTTPS), simply due to the fact that the communication over HTTPS is one-to-one. Meanwhile, e-mail is often one-to-many, or even many-to-many. Not to mention that you can't force encryption all the time over mail, since that would entail forcing the upgrade of all distributed e-mail servers and systems out there. I mean, how are you supposed to do that? The consequence of that is that even a safely encrypted e-mail may easily be leaked the second it is forwarded through an unencrypted server, which happens surprisingly often. And when that happens, it's not just the one e-mail that is leaked, but possibly the entire thread of e-mails being sent with it previously, which kind of renders the entire point e-mail encryption moot.

> I don't think they were horribly botched.

They were, S/MIME and PGP implementations are both god-awful. The standards leave too much up for interpretation and they leave a bunch of semantic security issues.

> It's simply a very hard problem to tackle, much harder than, say, end-to-end encryption over HTTP (which is of course HTTPS), simply due to the fact that the communication over HTTPS is one-to-one. [...] The consequence of that is that even a safely encrypted e-mail may easily be leaked the second it is forwarded through an unencrypted server, which happens surprisingly often.

This is mostly true. But I have to ask that people split up the technical challenges and the non-technical ones, the trust and encryption parts, the transport and message encryption aspects. All three pairs are very very different and pose different challenges.

It's technically totally doable to generate and distribute for example mailbox-validated S/MIME certificates. Vendors like Apple, Microsoft and Google could automatically request a certificate and store it in peoples' keychains or equivalent.

But with that there's the key storage part that's a bit more difficult though. Thanks to Passkeys/FIDO2 they're basically working on that, but this is the "technical trust" challenge.

It's not a technical problem however to verify the person behind a certificate. It takes a large enterprise or a country to verify someone's identity, not a trivial problem, though in either case some have done it. This is the "human trust" challenge.

Transport encryption is problematic, but you can in better configurations guarantee that letters until recipients are encrypted in transit. If a forwarder also respects MTA-STS, it solves that part.

However there isn't a MUA-STS standard that would force encryption on IMAP and SMTP like we have with HTTPS. This part is really quite dangerous and AFAIK no work is being done with that.

This is certainly not all there is to it, but these things can only be solved one-by-one and separate.

I think your comment misses the point a bit.

Sure, you might spend time on instituting complicated certificates and warnings. Of this you are of coure entirely correct. Except it's a lot harder to do right for many-to-many e-mail correspondences, that go through a multitude of different recipients and servers – some of which don’t use encryption at all – compared to the one-to-one browser communication, that goes directly to the end recipient, and stops there.

At that point the notion of “one-to-one encryption for e-mail” becomes completely meaningless, because it’s almost never actually one-to-one. The e-mail is frighteningly often sent to some intermediary party, inside or outside your organization, who you do not have any control over, and who will then forward that e-mail – encrypted or not – to the actual end recipient. What that means, is that no matter the amount of encryption schemes you throw onto an e-mail, the likelihood of a leak is still very high. And while undetermined or opportunistic third parties might not gain access to such a correspondence, a determined organization or state actor surely will.

As such, more encryption does not inherently make e-mail more secure. Especially when you know that there are multiple parties handling any given correspondence, with multiple clients and multiple servers – some of which do not use any form of encryption at all. You can never be sure that some user might simply forward the e-mail unencrypted – for whatever reason – down the chain of correspondence. For that reason, e-mail is inherently insecure and non-confidential, and it should be treated as such even if you strongly encrypt your own messages.

In fact, encrypting e-mail might lull you into a false sense of security, because the second that e-mail leaves your client, then the fate of that message is also completely outside of your control.

In order to fix this problem, you essentially need to create an entirely new e-mail system world-wide, with an entirely new protocol. Mozilla simply does not have that capability on its own, though motions to increase e-mail security is of course laudable.

You're very correct about the various terrible fallbacks. In some cases your own email client, totally capable of "E2E" encryption, might send out letters unencrypted (against our explicit request) without a warning! However I don't think all of email's current use-cases have to be covered perfectly with each attempt at an improvement to achieve a meaningful increase in integrity or confidentiality. This is also why I really wish these issues are kept as separate as possible.

Am I wrong to assume that our difference in perspective is how absolute of a confidentiality we're trying to achieve? The level I think you're describing is very difficult if not impossible even with the best we have right now. However I don't think that should be a showstopper.

I also disagree on the part about a "wholly new email", it's not really practically achievable.

Email is very unique in the sense that it's a massive ecosystem, but the components are really rather independent. Say if clients did S/MIME well we wouldn't have to care that much about MTA-STS for example, we absolutely should, but we wouldn't have to.

A bit of a tangent, but something like letter-strict-transport-security (LSTS) would be totally doable, we could add a header that makes email clients add additional safeguards against potential downgrades. "The letter you're trying to forward was requested to be kept confidential, are you sure you want to send it unencrypted to this recipient x?" After a decade passes we'll probably have a lot of clients that prevent basic mistakes.

> much harder than, say, end-to-end encryption over HTTP (which is of course HTTPS), simply due to the fact that the communication over HTTPS is one-to-one

Is it? Now, where the people no longer host their own websevers, but leave their content on services owned and operated by other people?

HTTPS isn't really E2E here.

Can I sign or encrypt some comment before posting it to make sure that only people I granted access to it can decrypt it or people can verify my signature on it with HTTPS?

If you are a webpage you could technically serve your page using Signed Exchanges (SXG) and then technically you could.

Access control can also be done with mTLS when the connection is established, so, technically only the people you grant access can read it.

No conspiracy needed.

HTTPS was already there and working more or less automatically, you just had to make it the default.

E-Mail end-to-end encryption is inherently more complicated to make work, as you need to put the user in charge of key management.

Browser vendors made a big campaign and invested effort into making HTTPS work. Noone did that for E-Mail.

Also it should be mentioned that the same level of security that HTTPS has almost exists in E-Mail. You have transport encryption, it is largely enforced on C2S connections. S2S is a bit more complicated, but even that is mostly solved by now via MTA-STS, which at least the larger mail providers support.

> HTTPS was already there and working more or less automatically

But that does fix the problem. That protects you against opportunistic tapping of wires. A bigger problem is the mass surveillance by POP, IMAP, SMTP and webmail providers (e.g. Google, Microsoft, Yahoo, Apple). They're not affected by HTTPS, because they're on one side of many of those HTTPS connections... and of course this is quite convenient for them.

If you want to be conspiratorial, you could note that Google funded Mozilla for quite a while, albeit only at a fraction of what it owed them in gained income due to having Mozilla / Firefox' default search engine be Google. And while TB was developed integrally alongside Firefox, it got a very small fraction of the resources.

---

BTW, Even E2E encryption doesn't resolve the surveillance problem properly, since those mass-surveillance operations get most of the headers / meta-data.

To me, this problem can be solved on a purely philosophical level. In other words, before delving into the technical aspects, one must address the fundamental question: “Do we want to encrypt as much as possible or not at all?”

At first, the argument in favour of maximum encryption may seem compelling. However, upon closer inspection, it falls apart. Essentially, it only makes it harder to read your correspondence for those who give up early. Meanwhile, determined parties, such as large organizations and state actors, can still easily read your correspondence even with this type of encryption scheme.

You might ask yourself, “But Mozilla told me that they would try to encrypt as much as possible!” Instead, the fact is that sometimes they will also have to forgo encryption, because the scheme can only encrypt most of the time. And it’s in those instances that determined parties strike!

As such, this kind of “encryption” scheme really only serves to lull people into a false sense of security, and that is often more dangerous than simply letting people know that their e-mails aren't encrypted at all.

So, for those of you who are inclined to believe in conspiracy theories, the real issue is not that e-mails have remained unencrypted until now. Once you understand that your e-mails are sent in the open, you can take appropriate precautions and avoid sharing sensitive information through e-mail. Meanwhile, if you think that your e-mails are confidential, you might be more inclined to let slip important secrets, when it’s actually being fully disclosed to any determined third party.

The false maxim is that more encryption is better than no encryption. Meanwhile it does not follow that more encryption equals more security or better confidentiality.

Nobody ever really solved the key exchange problem, and almost everyone values deliverability over confidentiality: one big failure mode of an encrypted system is your mail not being read by the intended recipient, and for most people for most use cases that's more important than guaranteed confidentiality.

Keybase is the closest I've seen to solving the key exchange problem, with their scheme for verifiably tying keys to user identity and user identities to users' online presences (websites, social media, etc.).

Unfortunately, it seems that key exchange alone isn't enough to build a sustainable business on, and, after attempting to be both Slack and Dropbox, they ended up getting aquihired by Zoom to do something only tangentially related. So the product's mostly stagnated.

HTTPS is just an encypted pipe. The authentication only works one way (you authenticate the server) and it only involves mapping a string (www.example.com for example) to the cryptographic identity through a trusted third party.

Encrypted email embodies an entire encrypted end to end messaging system with authentication of all the users involved in a discussion. The problem is harder and we have not settled on any good usability standard for this. The usability of end to end encrypted messaging is still quite bad for online connected media like instant messaging as well.

Actually, until a few years ago, browsers did support a rarely used feature for client TLS authentication and the <keygen> html tag.

> The problem is harder and we have not settled on any good usability standard for this.

Actually the CA/B Forum S/MIME workgroup just recently agreed upon the baseline requirements for future S/MIME certificate issuance. This also means an ACME-like process for mailbox-validated S/MIME certificates is or will be possible in the future.

Identity validation is a much more difficult, human problem. Some countries have solved that for their citizens, but due to how shit S/MIME has been so far, encrypted/signed containers have been used (a lot) instead.

My last company used S/Mime, but it required a dedicated appliance on both ends and a key server to provide the public key from the sending appliance to the receiving one. It's complicated and not practical for most people, but it worked quite well and is used by some big orgs.

That said, the bigger issue is how messages are stored at rest. Basically all the major email providers support and use TLS at this point, which is plenty strong enough for most mail in transit if you're only worried about the body of the message.

I think we need to worry about mail at rest before trying to make in transit encryption stronger. What's the point of anything stronger than TLS in transit if GMail can just read the full unencrypted message?

In normal encrypted email usage (without appliances at both ends) the emails are encrypted at any point after creation. They are only decrypted when someone wants to look at a particular message. So encrypted archiving comes for free. This is actually a significant and helpful feature here. I don't see the point of giving this feature up and then working to create a secure archiving system to make up for it.

> What's the point of anything stronger than TLS in transit if GMail can just read the full unencrypted message?

I thought the point was to make it so that if GMail reads the message body they see something like this:

which is probably not going to tell them anything useful.

That seems pretty useful to me. Sure, they still get to see the subject, the sender, and the recipient list so they get important metadata about my communications. But most of the time my communications are with people that I'm already known to communicate with, and the subject just reveals that the message is about some topic that I'm already known to communicate with them about. All the stuff that would actually be new and interesting to a third party is in the body.

On the other hand I seem to recall tptacek saying that just encrypting the message body is worthless, and when it comes to cryptography that guy's smart. I mean like fuck-a-guy smart. Know what I'm saying? So it is possible I'm overlooking something.

Not entirely worthless, but there are a bunch of things that are left unprotected and may thus pose an issue. Certainly not up to the same standards of your average EE2E IM platform, but it kinda doesn't have to be to be useful.

I totally agree. Se my "philosophical" reply further up if you want to delve more into the logical yet non-technical aspects of your argument.

It's because it's so easy to screw up. With E2E instant messaging the encryption is there by default for everything (in most apps anyway, looking at you, telegram). With email the default is unencrypted and there's so many ways for a user (either the sender or the recipient) to accidentally leak the whole chain in plaintext. So if it's actually important to you to keep the contents secret, email is not a good solution and cannot be reasonably made a good solution.

https://latacora.micro.blog/2020/02/19/stop-using-encrypted....

>With E2E instant messaging the encryption is there by default for everything...

The possibility of E2EE messaging is there by default. Most, if not all, base the critical identity verification on the comparison of super long numbers (just like PGP email). Pretty much no one does that, mostly because they don't know the basic concept behind such numbers.

Relevant:

* https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...

I think their point is that it's weird that the email protocols themselves were so insecure, when others got it right fairly easily.

Reply on news.ycombinator.com