5 ms·

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

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.
- kebman 4y ago
  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.
  - Avamander 4y ago
    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.
chme 4y ago
> 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?
- Avamander 4y ago
  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.

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.

kebman 4y ago
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.
- Avamander 4y ago
  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.

chme 4y ago

> 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?

Avamander 4y ago
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.