Live data from Hacker News

Convenient End-To-End Encryption for E-Mail

autocrypt.org

61–70 of 190 posts

Re: Convenient End-To-End Encryption for E-Mail

#61
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

I don't see the business world adopting "serious" secure messengers anytime soon. People don't want to send business stuff over WhatsApp, so we'll have to "bother" with email a couple decades longer.

But I really hate that I can't encrypt business communication, like invoices or contracts, without resorting to encrypted.zip. What's wrong with fixing that situation?

Re: Convenient End-To-End Encryption for E-Mail

#62
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

[deleted]

Re: Convenient End-To-End Encryption for E-Mail

#63
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

> but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.

There is a draft standard [1] for strict transport security. I'm not sure of its current status though.

> Email leaks metadata. In fact, some of what we call email "metadata" isn't even metadata --- stuff like subject lines are simply content. They're sent in plaintext.

Nothing sent during the data phase of the SMTP transaction has to strictly be unencrypted. There's nothing preventing the client from encrypting both the headers and body of the message. But that doesn't prevent the MTA itself from adding uncrypted headers to the message after the client sends the CRLF.CRLF sequence to end the data phase.

> Most email users get their email from a website. Unless you make them install something on all their computers

I'm not sure how many users still use a dedicated email client, but I'm sure that there are many who use clients like Outlook, Apple Mail, Thunderbird, amongst others. Anyone who wants to encrypt their email needs to know they need to use a client on their machine that handles the encryption/decryption steps for them (or that they need to do it themselves.

[1] https://www.infoworld.com/article/3046850/security/google-mi...

Re: Convenient End-To-End Encryption for E-Mail

#64
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

> It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear. SMTP has the exact same mechanisms, as does IMAP. HTTPS does not protect data at rest, and it doesn't protect data from the service provider, it never promised to. There is functionally no difference b…

I disagree, while also agreeing that IMAPS/SMTP-with-TLS is a huge improvement.

The big difference between HTTPS and SMTP is that there's an implicit extra hop. I go to send you an email. I connect to my outgoing mail server over SMTP-with-TLS, and anyone monitoring my connection cannot see the content of the message. Awesome! Likewise, you retrieve the message using IMAPS, and anyone monitoring your connect cannot see the content. Great!

But in between, there's absolutely no guarantee that my email provider sent it to your email provider over SMTP-with-TLS. It could very well have traveled completely cleartext, at which point it was harvested and archived by the NSA, with neither of our email providers having handed it over to them.

Re: Convenient End-To-End Encryption for E-Mail

#65
post #57
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

Oh look, another "middlebrow dismissal" ( https://news.ycombinator.com/item?id=4693920 ) upvoted to the top of a HN post. Color me surprised.

Not only that, but there is obvious bias whenever a popular HN user decides to chime in. I would wager that many people upvoted the comment without reading it... It's akin to voting ring behavior imo.

Re: Convenient End-To-End Encryption for E-Mail

#66
post #16
post #8

Unpopular but very probably true fact: email can't practicably be made secure, and people should stop trying. Email is itself archaic, and there aren't good reasons people should use it for routine peer-to-peer communications that need secrecy. Why? Because: * It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to p…

Good points, but email is so entrenched it might be easier to slowly fix the issues rather than throw it all out.

A large problem is that the companies with the money to address the issue will only do so starting from a position of a walled-garden rather than a system like email that in principle is open to anyone's mua/mailserver?

We have a proliferation of communication apps that don't talk to each other because each of the capitalistic driving forces wants to kill every other app so there's wins (even if there app is much worse than competitors).

This is where you need cooperation for progress and where capitalism, with greed as the driving force, utterly fails.

Re: Convenient End-To-End Encryption for E-Mail

#67
post #32
post #27

Earlier quoted context omitted.

You seem to be relishing this takedown post. I don't want to harsh on that, since I enjoy writing a takedown as much as anyone, but I have to point out that you're attacking an argument I didn't make. It's not my argument that people should use special secure messaging applications when they need security, and email at other times. It's that we should stop using email pretty much altogether. Like I said: it's archaic…

> It's that we should stop using email pretty much altogether. Like I said: it's archaic Sorry but have you ever used Signal or any other IM to send anything longer than a few sentences? Email can be as long as you want, and it is totally appropriate when you want to write a longer document.

Yes, you can write as long a message as you want with signal. There are desktop clients. You can attach files. Or voice messages. Or use it to call them. Or video chat them. It’s a crazy robust full featured incredibly secure communications system.

Re: Convenient End-To-End Encryption for E-Mail

#68
post #34
post #27

Earlier quoted context omitted.

You seem to be relishing this takedown post. I don't want to harsh on that, since I enjoy writing a takedown as much as anyone, but I have to point out that you're attacking an argument I didn't make. It's not my argument that people should use special secure messaging applications when they need security, and email at other times. It's that we should stop using email pretty much altogether. Like I said: it's archaic…

I’m pretty sure I want a big searchable archive, though. That doesn’t seem compatible with most of these security-oriented message schemes.

Protonmail seems to pull it off. Though at the moment encryption only works inside their system. They are actively working to implement the ability to send secure messages to people outside their service with GPG, though. I believe the CEO said it’d be ready by early 2018.

Re: Convenient End-To-End Encryption for E-Mail

#69

Earlier quoted context omitted.

> It's default-plaintext. We don't generally love the way websites ensure they're viewed securely, but email doesn't even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear. SMTP has the exact same mechanisms, as does IMAP. HTTPS does not protect data at rest, and it doesn't protect data from the service provider, it never promised to. There is functionally no difference b…

I disagree, while also agreeing that IMAPS/SMTP-with-TLS is a huge improvement. The big difference between HTTPS and SMTP is that there's an implicit extra hop. I go to send you an email. I connect to my outgoing mail server over SMTP-with-TLS, and anyone monitoring my connection cannot see the content of the message. Awesome! Likewise, you retrieve the message using IMAPS, and anyone monitoring your connect cannot s…

> But in between, there's absolutely no guarantee that my email provider sent it to your email provider over SMTP-with-TLS.

Don't accept non-STARTTLS traffic. Google doesn't, you shouldn't have to either. STARTTLS is widely available, and simply needs to be configured. Encouraging everyone to configure STARTTLS correctly is the easiest win we'll have.

And I hope you don't take what I said to mean that IMAPS and SMTP over TLS are a proper message encryption system. I simply meant that HTTPS doesn't do anything right that IMAPS or SMTP over TLS don't also.

Clearly there needs to be a standard way of advertising, distributing, transitioning, and retiring keys for email addresses. It needs to be robust, in continuity with existing infrastructure (probably domainkeys signed), straightforward (maybe signed proof of sender keys in a header), and possible to delegate in a way which meets the requirements of mailing lists. It also needs to be robust against malicious MTAs who could otherwise silently spoof senders and misrepresent their keys (double signing?).

A system with these properties would also solve the problematic interactions between DMARC and mailing lists which prevent almost everyone from deploying an appropriate DMARC policy today. If somebody is working on this I'd like to know about it.

Re: Convenient End-To-End Encryption for E-Mail

#70
post #27
post #22

Earlier quoted context omitted.

Your dimissive post boils down to “less than 100% perfect security is not ‘practicable’ so let’s leave a massively used, default communication platform utterly unsecure.” At least three of your critiques of encrypted email could be made of HTTPS: it leaks metadata (what sites you visit and when), it is plaintext by default, and the archives of the secured material are persistent and searchable. Yet HTTPS is hugely va…

You seem to be relishing this takedown post. I don't want to harsh on that, since I enjoy writing a takedown as much as anyone, but I have to point out that you're attacking an argument I didn't make. It's not my argument that people should use special secure messaging applications when they need security, and email at other times. It's that we should stop using email pretty much altogether. Like I said: it's archaic…

I think it's naive to expect email to be replaced any time soon. Despite all the attempts over the years, it remains and persists. There are essentially no major ongoing efforts to replace it by any of the big players, which is what would be required.

IM is not a substitute and never will be.

Post reply on HN