3 ms·
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
by 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 agoYou'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.