Live data from Hacker News

How to make e-mail encrypted for everyone

friendlybit.com

31–40 of 47 posts

Re: How to make e-mail encrypted for everyone

#31

The goal of encryption in email boils down to preventing your email provider from being able to read the email. (If you don't want to prevent that, then your email is already encrypted from everyone else if you and your recipient uses SSL and you use major email providers that try SSL over the internet backbone). Keeping your email provider away means your email provider can't have your private key, which means you n…

I don't agree with this. Compare to how your bank has access to your bank statement. In an ideal world that wouldn't be the case, only you would have access to it, but making sure that you use HTTPS when accessing your banks website.

So: It's not perfect, but it's better than what we have today.

Re: How to make e-mail encrypted for everyone

#32
post #20

> Since we need to know who to send the e-mail to, we should encrypt everything except the recipient address. I would argue all that should be unencrypted us the recipient domain , just like https

I agree this would be a good thing. Problem is that then the access of the public key needs to be encrypted too, which in turn means you need to make sure you use HTTPS. I think this would be a good thing, but I'm hesitant to make it an requirement.

Re: How to make e-mail encrypted for everyone

#33
post #25

Earlier quoted context omitted.

Exactly, but the author of the post didn't realize that. Instead > Some may frown reading that I suggest leaving the private key in the hands of your e-mail provider. I agree that this means you lose some privacy to your e-mail provider. It completely defeats the purpose of encrypting the message. If you are sending encrypted email from (example) your Gmail account to another Gmail account, the message must be totall…

I can see huge problems i educating people to look after their private keys. Imagine how many people would lose their keys and their entire mail archive is unreadable. Just this week I had TWO colleagues separately losing their respektive 2FA for github. And they both work in IT, one had saved the recovery codes, but couldn't make them work, the other not. In a time of cloud convenience, people are actually less and…

iCloud Keychain can still be recovered without any trusted device. They have some kind of escrow system for recovery. It was mentioned in the talk given recently by one of their security people.

Re: How to make e-mail encrypted for everyone

#34
post #21

To make sure I fully understand the proposal, it is to: 1. Generate public/private key pairs for all mailboxes at a given domain 2. Publish the public key in a DNS record at the mailbox domain 3. Encrypt message bodies with that public key in the MUA at send-time A few comments (assuming I understand correctly): First, this sounds a lot like SMIMEA ( https://tools.ietf.org/html/draft-ietf-dane-smime-00 ) or OPENPGPKE…

What you're missing is the proposal to have the email provider generate public key/private key pairs and somehow communicate that detail to the email client. (Presumably via some IMAP or POP query?). The current IETF drafts have no provision for how to communicate public keys and private keys to the email provider. I'll also point out that S/MIME 3.1 lets you encrypt message headers by including an entire message/rfc…

True, I've not included a specification for doing that.

Re: How to make e-mail encrypted for everyone

#35
post #3

It's too late to fix email. Neither using GPG (as the article points out) nor anything else. Ubiquitous, opportunistic transport encryption is the best it'll get, and we're pretty close to that. The future of secure communication isn't email, it's incompatible, centralized silos of low-latency protocols with forward secrecy. Think WhatsApp or Signal.

"The future is [whatever I see in front of me today]!"

It's a very common statement, whether we recognize it or not. It may be true in the short term, but it's unlikely in the long term.

Re: How to make e-mail encrypted for everyone

#36
Key management also needs to get a lot simpler and there need to be best practices!

If I only have one key for everything, it's quite dangerous for the key, because it must be on all my devices. If I create a key for each device though, how do you know which key to use? And the more keys I create the more I need to remember which is for which, when to replace one, etc. Last but not least it is REALLY HARD to erase stuff from smartphone memory. So the moment you put your key there you should know that other people will get their hands on, read your decryptet emails on the phone etc. There must be a way for me to kill it without completely erasing it, or at least a best practice for how to handle that.

Altogether I don't feel like PGP is meant for the 21st century. Or I just am not not smart enough to figure out how to make it work. I always spent a lot of time on it, and wasn't able to read all my email whenever I needed.

Re: How to make e-mail encrypted for everyone

#37
As many others have pointed out - this doesn't keep the email encrypted from the providers at either end.

We're already basically there for what this is suggesting - opportunistic TLS between providers is so high that the only sites that aren't doing it are the ones who aren't going to be deploying any new solution either.

And it still requires secure DNS to avoid being MITM degraded. Once you assume secure DNS is reliably deployed, lots of things become easier - but you still don't need encrypt partial payloads, because there's no "middleman" unless you're using a forwarding service.

And if you're using a forwarding service, who's publishing the DNS keys? This solution didn't address that at all, the forwarding service would have to decrypt the email with the key for the alias name, then re-encrypt it to the final destination. Either that or proxy the key request, which is trivially MITMable.

Upshot - this adds complexity and theater but doesn't protect against any credible attack vector.

As for the "coffee shop reads your email". Please. Basically every server who cares about security (the audience for ideas like this) already disables non-encrypted SMTP/IMAP/POP. At FastMail we only open the ports for SSL, because STARTTLS is nice, but it's MITM removable, and even if we reject login with the plaintext password, it's already been over the wire.

https://www.fastmail.com/help/technical/ssltlsstarttls.html

I'm too lazy to find one of those checklist things to paste about why this won't work, but I'm not jumping to implement it.

Re: How to make e-mail encrypted for everyone

#38
post #21

To make sure I fully understand the proposal, it is to: 1. Generate public/private key pairs for all mailboxes at a given domain 2. Publish the public key in a DNS record at the mailbox domain 3. Encrypt message bodies with that public key in the MUA at send-time A few comments (assuming I understand correctly): First, this sounds a lot like SMIMEA ( https://tools.ietf.org/html/draft-ietf-dane-smime-00 ) or OPENPGPKE…

What you're missing is the proposal to have the email provider generate public key/private key pairs and somehow communicate that detail to the email client. (Presumably via some IMAP or POP query?). The current IETF drafts have no provision for how to communicate public keys and private keys to the email provider. I'll also point out that S/MIME 3.1 lets you encrypt message headers by including an entire message/rfc…

I wasn't aware of that, but of course the destination is still leaked via RCPT. If the server is going to provision keys (and presumably thus escrow them), this is strictly less private than using server-to-server encryption.

Re: How to make e-mail encrypted for everyone

#39
post #2

> When you send an e-mail today it’s sent in plaintext. This means that when you connect to your local coffee shop’s WiFi they can intercept all e-mail that is sent through their router. This is probably not the relationship you have with your barista… Um, how many users use native clients on unencrypted ports as opposed to https based web-clients or TLS?

A worrying number of small companies who hire "an IT guy" who will promptly install an unpatched old version of Exchange Server and only turn on POP3. (Yes, paying for Exchange and not having ActiveSync.)

This is why the best thing for most small companies is to just use hosted Google or Microsoft mail.

Re: How to make e-mail encrypted for everyone

#40

As many others have pointed out - this doesn't keep the email encrypted from the providers at either end. We're already basically there for what this is suggesting - opportunistic TLS between providers is so high that the only sites that aren't doing it are the ones who aren't going to be deploying any new solution either. And it still requires secure DNS to avoid being MITM degraded. Once you assume secure DNS is re…

"At FastMail we only open the ports for SSL"

Does that mean that you do not support user mail submission on port 587 at all?

Post reply on HN