4 ms·

Hey 'tptacek and 'lvh. You definitely make valid points. But your arguments here on HN could perhaps be reduced if you adequately framed the problem: RFC 822/2

Hey 'tptacek and 'lvh. You definitely make valid points. But your arguments here on HN could perhaps be reduced if you adequately framed the problem: RFC 822/2822/5322 e-mail, on top of RFC 5321 SMTP and RFC 3501 IMAP, can't be secure. (And more RFCs I'm probably forgetting). To most people in the target audience (LARPers, technologist, and others), "email" isn't necessarily that. It's whatever Google/Outlook/... does for them. It isn't a concete set of protocols. But a _type_ of messaging. A particular set of ergonomics. When framing it from that perspective, people (programmers?) will go "well duh". Then we can move on from the unproductive discussion about semantics and move on to defining new standards, clarifying threat models, and building a real replacement people and companies will adopt. It'll take a lot of coordination and cooperation that can't happen until we've convinced enough people what the real problem is. And as long as we're using vague, subjective terms like "email", I don't think we can.

tptacek 7y ago
Nobody is going to adopt a new email standard that lacks the problems SMTP has. People will instead build new secure messengers that come closer and closer to the ergonomics of email, and that's what people who see a future for "secure email" should be looking towards, not some doomed effort to get the Internet to migrate to a new email protocol.
- cipherboy 7y ago
  Hmmm perhaps. But while we keep calling "email" the problem, we limit ourselves to creating "not-email". That's an admittedly large box, but when $politician and $businessperson is still addicted to "email" and asks for it by name, you can argue as much as you want, but not get 100% traction. It is a people problem. A naming problem. A publicity problem. IMO, better to leave "email" open as a generic term, with the hopes that one of these new messengers (hopefully, Signal) can eventually be standardized and opened to other implementations for adoption inside $bigcorp. But what do I know?
  - tptacek 7y ago
    I don't know what you know, but I can say that Signal and Signal Protocol have protected so many more messages than PGP that, by comparison and to a rough first approximation, we could say that PGP has protected effectively no messages. Signal isn't even the most popular messenger with end-to-end encryption, and its uptake so far outstrips that of PGP email that the two aren't even comparable. So appeals to the email userbase aren't especially interesting to me. My concern is that nerds are continuously trying to convince normal people that they should be encrypting email. That's dangerous, and wrong.
    - cipherboy 7y ago
      Then say that. Look, your article reads as a general attack on (encrypted) email. Independent of how it is implemented. You mention "PGP" 7 times: 5 times buried in the last paragraph of the intro, 1 time in a random paragraph on key rotation, and 1 time at the very end, as if your entire post was about PGP specifically. Hell, your title doesn't even mention PGP. You mention "identity" 3 times, "metadata" 5 times, "keys" and "plaintext" 9 times each, "user" 11 times, "messages" 23 times, and the substring "encrypt" a whopping 41 times. IMO that "plaintext" and "PGP" are roughly equal in usage--and that "encrypt" dominates that!--says something far stronger. Here you're here saying "this post is about no PGP" and I'm saying "but you wrote no (encrypted) email". I'm in agreement about PGP. I'd even go a step further and say you could say any encryption scheme on top of or underneath email would be weak. (Filippo's age? Jason's wireguare? $unicorn? etc.) Why? Because of the concerns you enumerated in the post that are fundamental to the way the above RFCs work. --- Think of the numbers and relative scales. x < 0.0001% of email users encrypt using PGP. and LARP. Fine. Attack those users in your blog posts and comments. But y >>> x of emails users play some part in replacing email in the grand scheme of things, with a more secure alternatives. The expected impact of writing a blog post and convincing ~nobody to quit using PGP is much, much smaller than writing a block post and convincing someone to start consider building, investing in, or supporting others to build that replacement. And IMO, you're 99% of the way to the latter, and 80% of the way to the former.
      - tptacek 7y ago
- deleted 7y ago
  [deleted]
- rocqua 7y ago
  What we need is something with the interface of outlook or gmail, where you can send messages and attachments to address much of the form username@domain.com where delivery of the message is under control of the owner of 'domain.com'. These are the ergonomics that people call e-mail.
bsder 7y ago
One use case I don't see mentioned, though, is "I sent you an email that I think you might tamper with the contents of. By doing authenticate and then encrypt, you might be able to claim you never got it, but I prevent you from claiming the email to be different than it is."
- lvh 7y ago
  You can generally just claim that it was never signed, so you usually need some other mechanism (technical or legal) anyway. This does work the other direction (term of art “non-repudiation”), where the sender can’t claim the message wasn’t theirs or said anything other than what it said. That’s generally considered an undesirable property for messaging systems (because the privacy trade off) but as you point out there are use cases.
  - AstralStorm 7y ago
    Crucial use cases. Official digital signatures use X.509 (including S/MIME) for this exact reason.

tptacek 7y ago

Nobody is going to adopt a new email standard that lacks the problems SMTP has. People will instead build new secure messengers that come closer and closer to the ergonomics of email, and that's what people who see a future for "secure email" should be looking towards, not some doomed effort to get the Internet to migrate to a new email protocol.

cipherboy 7y ago
Hmmm perhaps. But while we keep calling "email" the problem, we limit ourselves to creating "not-email". That's an admittedly large box, but when $politician and $businessperson is still addicted to "email" and asks for it by name, you can argue as much as you want, but not get 100% traction. It is a people problem. A naming problem. A publicity problem. IMO, better to leave "email" open as a generic term, with the hopes that one of these new messengers (hopefully, Signal) can eventually be standardized and opened to other implementations for adoption inside $bigcorp. But what do I know?
- tptacek 7y ago
  I don't know what you know, but I can say that Signal and Signal Protocol have protected so many more messages than PGP that, by comparison and to a rough first approximation, we could say that PGP has protected effectively no messages. Signal isn't even the most popular messenger with end-to-end encryption, and its uptake so far outstrips that of PGP email that the two aren't even comparable. So appeals to the email userbase aren't especially interesting to me. My concern is that nerds are continuously trying to convince normal people that they should be encrypting email. That's dangerous, and wrong.
  - cipherboy 7y ago
    Then say that. Look, your article reads as a general attack on (encrypted) email. Independent of how it is implemented. You mention "PGP" 7 times: 5 times buried in the last paragraph of the intro, 1 time in a random paragraph on key rotation, and 1 time at the very end, as if your entire post was about PGP specifically. Hell, your title doesn't even mention PGP. You mention "identity" 3 times, "metadata" 5 times, "keys" and "plaintext" 9 times each, "user" 11 times, "messages" 23 times, and the substring "encrypt" a whopping 41 times. IMO that "plaintext" and "PGP" are roughly equal in usage--and that "encrypt" dominates that!--says something far stronger. Here you're here saying "this post is about no PGP" and I'm saying "but you wrote no (encrypted) email". I'm in agreement about PGP. I'd even go a step further and say you could say any encryption scheme on top of or underneath email would be weak. (Filippo's age? Jason's wireguare? $unicorn? etc.) Why? Because of the concerns you enumerated in the post that are fundamental to the way the above RFCs work. --- Think of the numbers and relative scales. x < 0.0001% of email users encrypt using PGP. and LARP. Fine. Attack those users in your blog posts and comments. But y >>> x of emails users play some part in replacing email in the grand scheme of things, with a more secure alternatives. The expected impact of writing a blog post and convincing ~nobody to quit using PGP is much, much smaller than writing a block post and convincing someone to start consider building, investing in, or supporting others to build that replacement. And IMO, you're 99% of the way to the latter, and 80% of the way to the former.
    - tptacek 7y ago
deleted 7y ago
[deleted]
rocqua 7y ago
What we need is something with the interface of outlook or gmail, where you can send messages and attachments to address much of the form username@domain.com where delivery of the message is under control of the owner of 'domain.com'. These are the ergonomics that people call e-mail.

bsder 7y ago

One use case I don't see mentioned, though, is "I sent you an email that I think you might tamper with the contents of. By doing authenticate and then encrypt, you might be able to claim you never got it, but I prevent you from claiming the email to be different than it is."

lvh 7y ago
You can generally just claim that it was never signed, so you usually need some other mechanism (technical or legal) anyway. This does work the other direction (term of art “non-repudiation”), where the sender can’t claim the message wasn’t theirs or said anything other than what it said. That’s generally considered an undesirable property for messaging systems (because the privacy trade off) but as you point out there are use cases.
- AstralStorm 7y ago
  Crucial use cases. Official digital signatures use X.509 (including S/MIME) for this exact reason.