4 ms·

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 wen

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.

londons_explore 4y ago
Basically, "delayed by human factors". I wonder how such human factors could be reduced/eliminated?
jwr 4y ago
> 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).
- hannob 4y ago
  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.
  - einpoklum 4y ago
    > 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.
  - kebman 4y ago
    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.
- pjc50 4y ago
  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.
  - JonathonW 4y ago
    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.
- Technotroll 4y ago
  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.
  - Avamander 4y ago
    > 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.
- upofadown 4y ago
  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.
  - Avamander 4y ago
    > 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.
  - 0x0 4y ago
    Actually, until a few years ago, browsers did support a rarely used feature for client TLS authentication and the <keygen> html tag.
- Geezus-42 4y ago
  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?
  - upofadown 4y ago
    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.
  - tzs 4y ago
    > 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: -----BEGIN PGP MESSAGE----- hF4DiRYQNnty8w4SAQdAdiM2arHOheTBYTJriZZQOarZJy39Hs2Hl2tbAM/n5yMw 3DrQEjbJtP2LAm1oxaKPI3cyL05OFMU4p5ZMzbNIChEgNG7dxrUZJ9/0aS1P/8hl 0lkBHVB0DPdgxtLk7tl23iozcnoP4Heua1Lvqf891Cy51409FHk4UX/hUPwg2E/O mRczP2UVrbBB90CA0L0wRFfXZpPTtq0UusAtPZ4evtzEgcH4pDK5LV7hog== =vlQ3 -----END PGP MESSAGE----- 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.
- rcxdude 4y ago
  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.html https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
  - seanw444 4y ago
    I think their point is that it's weird that the email protocols themselves were so insecure, when others got it right fairly easily.
  - upofadown 4y ago
    >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-when-signal-hits-the-fan-on-the-usability-and-security-of-state-of-the-art-secure-mobile-messaging.pdf https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...
upofadown 4y ago
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.
- psychphysic 4y ago
  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. Or am I just adding to the bike shedding?
- kebman 4y ago
  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.

londons_explore 4y ago

Basically, "delayed by human factors". I wonder how such human factors could be reduced/eliminated?

jwr 4y ago

> 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).

hannob 4y ago
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.
- einpoklum 4y ago
  > 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.
- kebman 4y ago
  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.
pjc50 4y ago
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.
- JonathonW 4y ago
  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.
Technotroll 4y ago
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.
- Avamander 4y ago
  > 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.
upofadown 4y ago
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.
- Avamander 4y ago
  > 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.
- 0x0 4y ago
  Actually, until a few years ago, browsers did support a rarely used feature for client TLS authentication and the <keygen> html tag.
Geezus-42 4y ago
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?
- upofadown 4y ago
  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.
- tzs 4y ago
  > 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: -----BEGIN PGP MESSAGE----- hF4DiRYQNnty8w4SAQdAdiM2arHOheTBYTJriZZQOarZJy39Hs2Hl2tbAM/n5yMw 3DrQEjbJtP2LAm1oxaKPI3cyL05OFMU4p5ZMzbNIChEgNG7dxrUZJ9/0aS1P/8hl 0lkBHVB0DPdgxtLk7tl23iozcnoP4Heua1Lvqf891Cy51409FHk4UX/hUPwg2E/O mRczP2UVrbBB90CA0L0wRFfXZpPTtq0UusAtPZ4evtzEgcH4pDK5LV7hog== =vlQ3 -----END PGP MESSAGE----- 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.
rcxdude 4y ago
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.html https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
- seanw444 4y ago
  I think their point is that it's weird that the email protocols themselves were so insecure, when others got it right fairly easily.
- upofadown 4y ago
  >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-when-signal-hits-the-fan-on-the-usability-and-security-of-state-of-the-art-secure-mobile-messaging.pdf https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...

upofadown 4y ago

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.

psychphysic 4y ago
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. Or am I just adding to the bike shedding?
kebman 4y ago
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.