5 ms·
I'm not sure why you feel like calling my arguments pathological, or a false equivalence. I'll disregard this. I did not introduce any equivalence about valuat
by leshokunin 7y ago
I'm not sure why you feel like calling my arguments pathological, or a false equivalence. I'll disregard this.
I did not introduce any equivalence about valuation in my argument. I used Bitcoin as an example of a well known open database, where everyone can see the data (arguably an analog to plaintext exchanges) and yet it's secure.
Additionally, your point about Bitcoin being pseudonymous also applies to email. You may create your own address, on any number of servers. At a high level, it feels like the pseudonimity is essentially the same.
Are you proposing people stop using email and switch to a more secure messaging system, like Signal? Or maybe to make an email app on top of tech similar to Signal (kind of like Protomail?), or to improve email by baking in modern security standards?
- lvh 7y agoI did not call your arguments pathological, I called my own examples pathological to clarify that I am not trying to strawman you: I appreciate that my own examples are almost certainly not what people have in mind when they talk about email security. The pseudonymity is precisely one of the reasons e-mail does not work well. One of the features of secure messaging as it is commonly understood is participant privacy: hiding who participates and ideally when. This is the metadata leakage problem described in the post. You're restating your argument of "bitcoin is public and yet it is secure and so it is possible to have secure systems that are public". I understand that, but you don't appear to have engaged with my counterargument: "secure" is not a universal term, and things that are fine bitcoin transactions are not necessarily fine for secure messaging. Protonmail does not seem like "tech similar to Signal" to me at all. I'm all for implementing stuff like MTA-STS, and I appreciate e-mail isn't going to die any time soon. I think that trying to add E2E-style encryption to e-mail is fundamentally doomed, signing for e-mail is mostly doomed, and yes, private conversations belong on something like Signal.
- leshokunin 7y agoI appreciate the clarification, thanks. It’s interesting that you feel email has a lot of traction and is broken, but you see that as an argument for moving away from it. I would think it’s an opportunity to fix that system, since users are unlikely to switch. I’ve thought quite a bit about what making email like Signal would look like, but I’m curious what’s your take on the overall problem.
- lvh 7y agoI do not think it is meaningfully possible to fix that system (I say meaningfully, because I'm excepting the pathological senses I mentioned above). If you want it to look, feel like email and be compatible, you can't secure it. MTA-STS works because it does not require end users to do anything. If you need end users to change their workflow, you could try to do that with e-mail (which fundamentally can't do all the things you need it, per the post and the PGP post), or you can just make them use a non-broken protocol.
- leshokunin 7y agoI guess I don’t understand why you would think that the following wouldn’t work: - use random email addresses - encrypt the content with something more secure than PGP (on the client) - receive the email and decrypt it (on the client) Sure, it’s plaintext, but I don’t see the downside?
- lvh 7y agoHow do I securely communicate what the new email address is? How do I hide IP-level metadata? How do I hide time-level metadata? How do I do PFS? At some point you're going to keep adding lipstick to the pig until eventually you have something morally equivalent to the pathological example I gave.
- leshokunin 7y agoThat's interesting. Thanks for taking the time to expand on it.
- the_hoser 7y agoThe security flaws with email are completely fundamental. It is not possible to "fix" email without disrupting the existing users. If you're forced to disrupt existing users, then you might as well switch to a more securely designed protocol.