Comment by cipherboy | Hacker News Reader

Comment by cipherboy | Hacker News Reader

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.

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.

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?

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.

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.

I can't say this any better than the article already does. If we replaced PGP with Age (a cryptosystem I like), email would still not be safe --- for all the reasons the article gives. This is not simply an argument about PGP.

tptacek: > This is not simply an argument about PGP.

That's what I was just saying... Go reread it!

But you also wrote:

> My concern is that nerds are continuously trying to convince normal people that they should be encrypting email. That's dangerous, and wrong.

I'm (just) trying to convince you to broaden the stated impact of your post. You're wanting table scraps from people who won't listen and who have no impact in turn. Ask for something bigger from people who might but have lots of impact when they do. You're nearly there.

> 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

I can believe it about Signal protocol, since it’s implemented on Whatsapp and Facebook Messenger. But, if you talk just about Signal proper, are you sure it protected more messages and more people than PGP?

I see this claim fairly often, but no data to back it up

Anecdotally I've received e-mails from two people with S/MIME or PGP signatures and zero encrypted e-mails. There are about a dozen people in my contact list with Signal, some of whom I exchange messages with regularly.

It is causing issues for forensics (before that people were using SMS, IMAP, and SMTP; all without TLS). It isn't fool proof, for example if your adversary can gain access to Google Drive or iCloud via a warrant. Although making backups via such platforms is optional.

> IMO, better to leave "email" open as a generic term

Be conservative in what you do, be liberal in what you accept from others

If you attempt to redefine the term 'email' to be something broader, then you will inevitably be breaking and/or confusing users who expect the current implementation.

The current meaning of the word is simple and useful. Given someone's e-mail address, I can be reasonably sure of a way to send a text that will be received.

A world where 'e-mail' means a family of incompatible (by necessity, if we're enforcing secure communications) implementations would be worse than today.

Would you, in ~10 years, prefer a new standard (Signal-Mail, RFC 424242) and have "secure" (for a given definable threat model) standard called email that obsoletes the above RFCs and has 80% market share over current email standards...

...or have 30 different walled-garden, not-interoperable, partially-working (for a given ergonomic use case) apps?

Considering that much of present day communication happens on async on email (including important conversations inside and between banks, governments, land-lords and tenants....), I'd say its something that should happen. And if we can convince the right people, it will happen. We'll live for the next ~5 years in a state of hell (just like we do when we upgrade TLS protocols), and then for the majority of people, things will get better.

My 2c.

And to expand on this a little:

Users don't care. They'll use whatever is given to them, as long as there is no friction. That's why PGP-encrypted email never took off, except as something that tptacek likes to argue against.

Concretely, we (the security-conscious community) need to convince people (engineers, executives, managers) at Google, Microsoft, Oracle, countless other companies, and a myriad of open source communities that this is something important to build, invest, and collaborate on.

The first part is messaging. Then comes networking, convincing individuals in private. Then comes public collaboration. Proof of concepts, test networks, RFCs, production apps.

But until there's a need and money, this won't happen. And it'll be people arguing past each other on the internet.

> ...or have 30 different walled-garden, not-interoperable, partially-working (for a given ergonomic use case) apps?

In having to choose from about 5 to 6 that I have to now, it would certainly be a nightmare if it fragmented to 3 dozen or so. That would be a major problem.

> If you attempt to redefine the term 'email' to be something broader, then you will inevitably be breaking and/or confusing users who expect the current implementation.

An interesting parallel could be Apple's introduction to iMessage in the Messages app, to the point where many use the word "text" to actually mean "sending an iMessage".

This is the same problem faced by another worthy goal, replacing DNS. What does cipherboy.example.com even mean, without DNS? Similarly, what does cipherboy@example.com mean without SMTP?

It's a hard problem. If I tell someone "my email address is samatman@newawesomeemail.com, no, you can't email me from gmail you have to use AwesomeEmailClient", they're going to be confused and nonplussed.

If they can email me from gmail, well, they will. And I have to reply with SMTP, and nothing useful was accomplished.

What is a worthwhile replacement to DNS? We don't have one. That's part of the problem: differences of opinion.

Try HTTP/HTTPS: we have separate ports, browser preferences, and lots of unified messaging deprecating HTTP.

Suppose we reuse the same format (name@dom). What would a migration plan look like?

Early stages: - DNS record indicating support. - Separate ports. - Reduced spam (because nobody is using it). - No warning messages.

Mid stage: - Lots of dual-stack systems. - Something like HSTS and preloading. - Warning indicating insecure delivery (the client can detect this). - Buy-in from most large corps (Gmail...)

Late stages: - Old, insecure port goes away almost entirely. - Revisions to spec, improvements.

We're still at the tail end of this for HTTPS, and we're building on top of a well-known, supported encryption protocol (TLS, which gets reused elsewhere).

The point is, if Gmail doesn't buy in, you've not made meaningful progress, because they have billions of users alone. And unless they move, most large corps/... won't also move.

That's, in my opinion, why Signal and stuff (while nice, secure, ....), won't replace email.

So how do we get there?

First we need a security protocol with the constraints outlined in the post. - Forward secrecy, - Handles key rotations, - Notifies of device changes potentially. - ...

That's going to take time to design, develop, and standardize. Whether we tie the messaging protocol and format (SMTP/...) tightly to the security protocol (TLS) remains to be seen. It takes time for formal verification too.

Then we need Gmail support. If it is a closed, non-standard protocol (like Signal), it won't be adopted. The RFC process is the only process I know that can influence those types of changes.

And yeah, now? It won't be secure. But we'll have a path from getting to "mostly plaintext" to "mostly secure". And we'll have to live with the fact that it takes time.

If you're not reusing the same address scheme, then yeah. You would have to educate a lot of people about the difference. But if you push that onto the developers, I think that's better. And you can make it mostly transparent to the end user, except at critical times.

Can we also stop pretending Signal was some genius stroke that happened in a vacuum? With all due respect to Moxie signal was born out of years of experience with OTR and SCIMP for XMPP and the need for asynchronous key exchanges in chat systems.

Moxie Marlinspike and Trevor Perrin.

Sure: is there a specific place where you feel I've done that? I think everyone involved would happily concede that Signal, like almost everything, stood on the shoulders of giants. It seems fine to both acknowledge that and also say that making it more accessible (literally go install this thing from the app store) and developing it further (the Signal protocol builds on OTR and SCIMP, sure, but Axolotl, 3XDH and the formalization of Noise are meaningful developments that also warrant recognition).

The thing that's hard to swallow is that you're recommending a plan that maybe solves the problem by 2050. Remember, STARTTLS was standardized 22 years ago and you still can't reject emails from servers that don't use it unless you're okay with missing business-critical messages, in my experience. Meanwhile, Signal works today. It would be cool if there was a group working on the solution you've laid out, and maybe it'll still be relevant when it arrives, but if you have any privacy needs before you retire we have to point you at Signal.

Sure, but HTTP was started in '97, and yet we've gotten a decent replacement rate towards HTTPS.

It's all about publicity and messaging. We made an explicit, coordinated push to get rid of HTTP. We're still working on it. Think of how many people were/are involved.

We've not had a coordinated push for SMTP. TLS doesn't satisfy anything but a trivial threat and trust model (for secure messaging, when done at the SMTP layer). And that would involve a lot less people if we get it "right" (and it's only a new protocol and not a new app).

If it were up to me (it's not), we'd have a solid technical spec and then try and make this happen. Rather than pushing STARTTLS.

There is kinda a group working on a solution. I don't know what the current status is and what their funding levels are:

https://darkmail.info/

For these purposes, the branding is all wrong. I've not read a recent version of the spec, but there's still commits as of 6 months ago.

Sure, but it seems to me that improving email is more similar to improving email than to improving HTTP. I think the STARTTLS push has gone more slowly than HTTPS for reasons that are fairly fundamental to email - it requires hitting more providers to get decent coverage. Chrome has >60% market share, while GMail is <30%.

> 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

Since it's obvious that no on-the-wire compatibility is possible, it's fair to give it a new name for branding/marketing. Sometimes the progress happens that way, the new name becomes fashionable with $politician and $businessperson and using "email" now signals your low status, etc.

BTW, the new-non-email could facilitate fighting spam and attention-fishing through some micro-payments scheme.

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.

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

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.

Crucial use cases. Official digital signatures use X.509 (including S/MIME) for this exact reason.

Reply on news.ycombinator.com