At first, a maintainer considered it to be a regression to implement (reading the bugzilla page), which caused it to be delayed for ~7 years. Then the issue went more or less inactive for almost a decade because the world at large dismissed OpenPGP encryption on mail as pointless (in part due to the complexity in actually getting it working since no mail client gave it a first class implementation, leading to a circular case of it not being implemented because nobody did it.)
2 years ago it was deliberately revived by Mozilla, then it devolved into bikeshedding about the design and now it's finally shipped.
> 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).
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.
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.
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?
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.
> 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.
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.
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.
>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.
The bikeshedding here came from a fundamental disagreement about usability. It really could not be helped. Some wanted the email client to automatically detect a situation where encrypted email was possible. Others felt that the risk of a user unknowingly sending a CC unencrypted was too high.
Part of this ended up coming from the fact that Thunderbird was not clearly showing the user that the email to a particular recipient was or was not going to be sent encrypted. I am not clear from skimming the discussion that this fundamental issue has yet been fixed.
It would have been better to implement and then rachet up use.
Just like happened with HTTPS.
At the start not many noticed or cared if their connection was encrypted. Then companies started directing people to the encrypted site and pointing out the padlock icon browsers adopted.
Now we're getting to the point that browser's might fuss about unencrypted connections.
Same could have been done but they got caught up in well if we have any encryption. It should all be encrypted false dichotomy.
The discussion is essentially about whether you want to lull people into a false sense of security by encrypting some e-mails, or having people self-censor because they know that all e-mails are sent in the open. As it is, encrypting some of the correspondence will only deter those third parties who give up early. Meanwhile any larger organization, such as a state actor, will still be able to easily read your correspondence even with such an "encryption" scheme.
I don't have any real information, but my guess would be the same as for any other feature in any other open source software: nobody stepped up and did the legwork until now.
The ethics of how to properly allow users to send both encrypted and unencrypted emails was an issue. Sending encrypted messages and plain text at the same time will defeat the idea of security and privacy. if there is a thread with many members that have both unencrypted and encrypted-capable messaging, then the encryption is unnecessary and becomes worthless. Eventually there was an agreement that having unencrypted as default is bad. There had to be a way to increase the amount of users enabling encryption. Implementation was halted as the brainstorming of how to make this feature was sidelined as it was lower priority. 19 years later, users made another push to bring this feature into mainstream. Developers saw that they had enough time to brainstorm this low priority feature. the larger user base allowed this feature to be brainstormed faster. after a year and half of feedback, the main developers were able to have this fully featured. This final implementation will allow users to be encrypting messages more often and not need to disable the encryption. More users will be able to use this client and less frustration from users who are unknowledgeable of technology. If there is a need for only encryption, then it is possible. This "automatic" feature is more desirable than forcing the sending unencrypted to all. There is a chance a thread will only have encrypted-capable members, and accidentally sending an unencrypted message in the thread is a bigger problem to privacy and security. The final consensus is that sending of messages should be the responsibility of the user, not the application. The applications should always try to send encrypted messages. Unencrypted messaging should be the users responsibility as there is now a possible way to discern a thread has encrypted-capable members or not.
TLDR: people argued whether it is bad or good feature, this was sidelined as low priority, users 2 years ago made a last push to implement this feature, They came to an agreement that responsibility of encryption is on message thread members and having unencrypted only is a worse option than the application sending encrypted where possible, feedback was collected on how the user experience should be implemented, and lastly the automatic selection feature was implemented.
Users should still look into how this was implemented and give feedback on possible security/privacy concerns that may need to be implemented when the automatic feature is enabled. types of toggleable features that should be implemented and may not be is confirmation dialogues, message encryption per recipient/thread, visual indicators of received/sent messages being encrypted/unencrypted, and more. This is up to the developers to implement this to the GUI. I have not explored the new feature in its entirety.
