
How to make e-mail encrypted for everyone - EmilStenstrom
https://friendlybit.com/security/how-to-make-e-mail-encrypted-for-everyone/
======
vbit
> 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?

~~~
EmilStenstrom
I don't have any stats, but I imagine lots of users still connect over
unencrypted ports directly to their ISP. We have to remember that most users
are not like the HackerNews demographics. If you have stats that points to
this conclusion being wrong I'm happy to change my mind.

~~~
Matt_Cutts
It looks like 80-85% of emails to/from Google are encrypted in transit,
according to this page:
[https://www.google.com/transparencyreport/saferemail/](https://www.google.com/transparencyreport/saferemail/)

Encryption at rest is still a difficult UX/UI issue, but encryption during
transit seems like something that most mail providers can get behind.

~~~
jcranmer
Note that this is MX-MX routing of emails between email providers, which sort
have has to allow plaintext in practice.

The question of user-level IMAP/POP/SMTP access is different, but I'd expect
somewhere in the region of 95+%. Note that the IMAP specification prohibits
authentication that sends passwords in the plaintext [1] (although I don't
know if the various IMAP servers permit AUTHENTICATE PLAIN before STARTTLS--
checking, Outlook doesn't, and the other servers I had access to aren't open
on 143 anyways), which means IMAP in practice _requires_ SSL.

[1] The alternative is to use schemes like CRAM-MD5 or SCRAM-SHA-1 which don't
send the password in plaintext, although these have become quite rare in
practice.

------
brongondwana
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](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.

~~~
EmilStenstrom
> there's no "middleman" unless you are using an e-mail forwarding service

Each time an e-mail passes through an e-mail service that service is required
to add a "Received" header to the e-mail. So you can easily check out of your
real e-mails to see if you are using any middleman or not. The first e-mail I
opened looks like this:

    
    
        Received: from exdb06.ug.kth.se (192.168.32.116) by exdb02.ug.kth.se
        Received: from mx5.kth.se (130.237.32.10) by exdb06.ug.kth.se (192.168.32.116)
        Received: from mx5.kth.se (localhost [127.0.0.1])
        Received: from mx5.kth.se ([127.0.0.1])
        Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24])
        Received: from relay.mailchannels.net (localhost [127.0.0.1])
        Received: from uscentral412.accountservergroup.com (ip-10-27-139-41.us-west-2.compute.internal [10.27.139.41])
        Received: from uscentral412.accountservergroup.com (uscentral412.accountservergroup.com [10.102.194.57])
        Received: from friendly by uscentral412.accountservergroup.com with local (Exim 4.87)

------
jcranmer
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 need some way to keep the key in sync
between different email clients--say desktop and smartphone.

~~~
pmontra
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 totally protected from Google to read, index,
possibly giving it to any third party. So, no encryption and decryption using
sw made by Google which could be changed in every moment to spy on you.

I just don't see how encryption could work in a web mail. Only client side
will do.

~~~
algesten
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 less inclined to
understand the concept of public key crypto and the importance of backing up
private keys.

Even if you trust say, apple's icloud keychain (which isn't necessarily a
great idea), it still requires access to a trusted device, and it's locked in.

So I think the biggest nut to crack is a unified cloud based private key
backup that seamlessly integrates with everything from web applications to
every OS and then get Microsoft/Apple/Google on board to support it every
where.

Not easy to pull off.

~~~
BillinghamJ
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.

------
Thespian2
Sounds like you are talking about Identity Based Encryption (IBE)

[https://en.wikipedia.org/wiki/ID-
based_encryption](https://en.wikipedia.org/wiki/ID-based_encryption)

There are mature, commercial products which use this to address the "PKI
benefits without the overhead of managing PKI" problems. Read the wikipedia
page for the gory details, but essentially, you get to use someone's email
address functionally as a public key (as per traditional PKI email schemes)
_wihtout_ the recipient having to, a priori, create the pub/priv keypair. They
can be derived statelessly on the fly.

For one example, See Hewlett Packard Enterprise - Data Security "SecurMail"
product.

Full disclosure: I work on this product.

Here is some basic background information on how it works.

[https://www.voltage.com/products/email-security/hpe-
securema...](https://www.voltage.com/products/email-security/hpe-securemail/)

There _is_ still a "trusted 3rd party" running the key generator (a deal-
breaker for some threat models of privacy) _but_ that generator entity doesn't
have to be the ISP or email provider involved at either end.

------
mjevans
The two biggest detraction points are completely valid:

1) The need to install ANY (non-standard) software (by definition -everyone-
should already be able to use it).

2) The need for users to manage their own keys.

I envision a solution to point 1 is making it a /feature/ of every OS to
implement the required software for the open protocol. Prototype on BSD/Linux,
get MacOS to ship slick versions of the protocol, and use THAT to club
Microsoft over the head for also shipping support with Windows.

Paired with point 1, smart USB attached keys. End users should think of that
as their signature and their 'mark' for signing official legal things and
literally inking a document with blood.

The USB key should at least have a few lights as an indicator and a couple of
buttons.

It should be easy for the user to:

* Allow it to AUTHENTICATE a provided datastream.

* Allow it to decode and provide the unlock key for a datastream back to the computer.

* Allow it to provide a signature for a datastream.

I order those in the least to most trusted operations it should perform.

It might, for a smarter device, support multiple keys or different trust
levels of keys.

With the above two frameworks in place all other problems become /far/ easier
to solve, and the user experience will be much better (so it'll actually
/happen/).

------
hannob
DNS-based key discovery has already been invented twice: PKA and OPENPGPKEY.
Nobody is using it. It has an obvious problem: DNS is not secure. There is
DNSSEC, but it's practically undeployed on clients, therefore building on it
doesn't make sense.

GPG recently added support for key discovery via HTTPS (Web Key Service, WKS).
That goes in the right direction, because it takes the best deployed working
authentication system - the web pki - and bootstraps from there.

~~~
EmilStenstrom
I don't think this is about inventing a new protocol. It's about getting Gmail
and Thunderbird on board. Has anyone put them in a room together?

~~~
ttul
Yes, we all got together this week in Paris.

~~~
EmilStenstrom
Who do you represent? Who got together?

------
vx17h
Keep a close eye at the pretty Easy Privacy (p≡p) project.

It provides an engine (written in C99) and adapters for the most important
environments, in order to automatize key management and message transport.

It'll be the default way to automatically encrypt e-mails in Enigmail, where
most OpenPGP traffic emerges from, anyways:
[https://twitter.com/pEpCouncil/status/791948659378106368](https://twitter.com/pEpCouncil/status/791948659378106368)

But that's just a start, as p≡p wants to transfer all text-based
communications anyhow into the censorship-resistant, peer-to-peer GNUnet
(using OTR or Axolotl crypto).

Cf. White Paper of p≡p: [https://pep.foundation/docs/pEp-
whitepaper.pdf](https://pep.foundation/docs/pEp-whitepaper.pdf)

(Wikipedia article on p≡p showing its broad approach:
[https://en.wikipedia.org/wiki/Pretty_Easy_privacy](https://en.wikipedia.org/wiki/Pretty_Easy_privacy))

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

~~~
vx17h
In p≡p there's both, automatic key management and a KeySync protocol (yet
being tested, not activated already) to sync private key material across the
devices you want to read the same messages on.

See the source code on that:

\-
[https://letsencrypt.pep.foundation/trac/browser/asn.1](https://letsencrypt.pep.foundation/trac/browser/asn.1)

\-
[https://letsencrypt.pep.foundation/trac/browser/sync](https://letsencrypt.pep.foundation/trac/browser/sync)

As you say correctly, of course you've to take care: as a common denominator
an id is used, in case of e-mail a certain mail address, whose e-mail channel
for communicaion functions as the key exchange channel, too (meaning the
devices send themselves messages ("beacons"), which are considered as
technical messages by the p≡p engine and thus never shown to the user as
such).

=> If you fear to have a cell phone hacked or lost, it's better to not put
that in a device group. Also you can seperate business from private accounts
or have different accounts and on top of that aliases for whatever purposes,
referencing the same id (mail address). In short: you can have (like mostly
today) no device group at all or just different device groups meeting your
needs and "paranoia levels" (based on the trust you put in your devices).

The devices agree on a device group key pair, being the master key pair, still
they sync all devices' private keys for that specific id, such that you can
read all of your messages received on all of your devices (even if there were
changing pubkeys in between used for encryption, because of your different
devices, which were not yet synced in the past).

If a device is lost or stolen, that has to be manually signalized by one of
the other devices in the device group and then the devices have to agree on an
new device group key pair to encrypt their future communications (we're
talking of PGP encryption here, so no forwad secrecy).

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

~~~
EmilStenstrom
I don't agree, people have declared the death of e-mail for many many years
now, it's not going anywhere. It's definitely not to late to fix it.

~~~
stefs
not death of all email - i think lima talks about that it's too late for per-
default end-to-end encrypted email. encrypted transport to/from the server is
relatively easy, but client-to-client? email wasn't really built that way and
now the barrier of entry for broad adoption is too high.

------
gravypod
> You need to install software on your computer. Most e-mail providers are
> moving to the web, having to install a browser plugin just to send e-mail is
> not the experience we should strive for. I understand that this is means
> your e-mail provider can read your e-mail, so it won’t work for everyone.
> But I think most people will accept that the same way they accept that their
> bank can read their bank statement. If we can trade this for usability it’s
> still a HUGE step up for privacy.

Yea we have that, it's called STARTTLS. If the keys arent only held by the
user then there really isn't any end-to-end encryption. It's just the same as
SSL.

------
swrobel
> 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

~~~
EmilStenstrom
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.

------
dwheeler
Here is the same idea from 2002: [http://www.dwheeler.com/essays/easy-email-
sec.html](http://www.dwheeler.com/essays/easy-email-sec.html)

~~~
EmilStenstrom
Nice find!

------
nickpsecurity
It's not going to work. All the main problems must be overcome in theory and
practice before it gets deployed. Here's a summary of them from Collin
Robbins:

[https://cybermatters.info/2012/08/13/why-has-encrypted-
email...](https://cybermatters.info/2012/08/13/why-has-encrypted-email-not-
taken-off/)

Note: He was one of LDAP's inventors. His company Nexor deploys both encrypted
mail and high-security guards regularly. That's his credentials.

------
owly
I'm impressed by the ProtonMail team. Yes, they have a way to go but are
making great progress. Yes, you need to trust them. Yes, it's simple enough
for my grandmother to use! The mobile app works well too.

------
md_
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](https://tools.ietf.org/html/draft-ietf-dane-smime-00)) or
OPENPGPKEY ([https://tools.ietf.org/html/draft-ietf-dane-
openpgpkey-02](https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-02)) DNS
records.

One requirement in this approach (not mentioned in the linked article) is that
this _only_ makes sense if you use DNSSEC. If you don't use DNSSEC, all the
threats that apply to opportunistic STARTTLS apply.

There are pros and cons of DNSSEC, and various deployment issues, but in
general SMIMEA and OPENPGPKEY are both basically workable. (Another option,
widely discussed but as far as I know not specified in a formal protocol, is
to use HTTPS and webfinger with CA-signed certs for key discovery.)

Second, I think there are a number of smaller errors in this blog post.

1\. The primary issue with STARTTLS is not the two listed here (lack of
encryption at rest, downgrades on "the whole chain") but rather the fact that
it is opportunistic and enforces no certificate authentication. So active MITM
attacks (DNS injection or stripping, to name a few) work. But they work on the
proposed scheme as well, since nowhere is it specified that we must use
DNSSEC!

2\. I don't understand how server-side key management avoids the encrypted-at-
rest issue, since the keys are stored on the server!

3\. The focus on client-to-server (i.e. MUA to MTA) connections seems spurious
to me, since (as others noted here) the vast majority of users use a handful
of MUAs that _do_ enforce SSL (mainly web browsers, Apple Mail, and mobile
mail clients like iOS Mail or Android's Mail app). The real issue is server-
to-server (i.e. MTA-to-MTA) connections.

4\. Encrypting message bodies leaks header metadata. Given the fact that this
proposal seems to primarily suggest server-side key management, it's not
really "end-to-end" encryption anyway, so it sacrifices metadata leaks to
gain...nothing. Doing transport-layer encryption between servers is
effectively a better option.

So tl;dr:

In broad strokes, the proposal makes sense and reads like a slightly less-
detailed version of a couple of existing IETF proposals. But as with
everything, the devil is in the details.

Hope that makes sense.

~~~
jcranmer
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/rfc822 inside an encrypted section. I don't think
any email client actually supports doing anything reasonable about that.

~~~
md_
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.

