Project Proposal: Let's Encrypt Email

Feature Requests
1

First of all, thank you for your efforts to spread transport encryption to make the internet more secure. I know you are probably very busy fixing last minute problems before the launch. Nevertheless I would appreciate comments on the following proposal.

Project Proposal: Let’s Encrypt Email

The goal of Let’s Encrypt Email is to establish a distributed infrastructure for easy-to-use end-to-end email encryption that is compatible with existing clients and offers a turn-key solution for the average user. In order to reach that goal I propose to use a hybrid scheme of S/MIME and PGP encryption that is backwards compatible with standard S/MIME email encryption, and some additional protocols and conventions that increase ease of use.

Motivation

In recent weeks we have seen some email providers adding support for PGP encryption in their web mail interfaces (for example German providers GMX and Web.de and an announcement from Yahoo). Unfortunately at least the German providers establish some kind of walled garden: they only solve the problem of initial trust between their own users; they make importing public keys from users of other providers unnecessarily cumbersome; and they make it difficult to use an existing key.

I think we can only reach broad acceptance and use of email end-to-end encryption if we provide a solution that works, no matter whether writing emails to the same or a different email provider. Even more I think that the solution should compatible to almost any email client or browser out of the box.

Hybrid Use of S/MIME and PGP

While the PGP seems more popular among experienced users, the PGP envelope format is unfortunately not understood out of the box by the vast majority of email clients. That leads to strange text in the email body (the famous BEGIN PGP SIGNED MESSAGE) or unknown attachments that irritate inexperienced users because they fear viruses. S/MIME is implemented in most email clients and also used in enterprise environments, but users need access to a certificate authority and more experienced users fear that there might be rogue CAs that sign malicious keys so that their communication with people they know over a few hops might be intercepted. In addition the X.509 certificate format is not very flexible, because it does not allow multiple signatures on one certificate and there is no widely adopted infrastructure to retrieve certificates for the initial contact, like PGP key servers.

I propose to use a hybrid scheme combined from S/MIME and PGP that is fully backwards compatible with S/MIME:

  • The user generates a normal PGP key (with a Features flag indicating that the client supports Let’s Encrypt Email) or imports an existing one.
  • The same public keys from the PGP keys are sent to Let’s Encrypt to be wrapped in a X.509 certificate and signed by the Let’s Encrypt CA (or another compatible CA). The certificate contains a non-critical v3 extension containing the PGP key ID and possibly a URL where the PGP key can be retrieved.
  • The user sends mails using the S/MIME envelope format, including the X.509 certificates derived from her PGP key.
  • Other users validate the signature from the S/MIME envelope using the included certificates.
  • If the email client of the receiver supports Let’s Encrypt Email, it retrieves the PGP key indicated in the X.509 certificate and builds a PGP trust chain. If the trust chain can be established, the email client indicates this additional verification to the user (similar to extended validation certificates in web browsers).
  • S/MIME-only email clients can just use the collected X.509 certificates for encryption. There is no possibility to send encrypted emails to receivers from whom the sender did not previously get an email that included her certificates (which is the status quo).
  • Email clients that support Let’s Encrypt Email or PGP can retrieve the PGP key of the receiver from a PGP key server or a similar well-known mechanism if it is unknown. If the PGP key indicates that the receiver supports Let’s Encrypt Email and the sender also does and there is no trust path, it will additionally fetch the corresponding X.509 certificates from a well-known location and verify that it is signed by a trusted CA. The email is encrypted using a PGP envelope.

For compatibility with PGP-only tools we could try to work on support for the S/MIME envelope signatures in the standard GnuPG tool suite and library and other widely used PGP software such as Mailvelope.

Advantages:

  • Initial trust for unknown public keys via the X.509 PKI. That leads to a lower barrier of entry, while at the same time providing for some authentication of the public key which is a major improvement over just trusting unauthenticated keys (that’s what inexperienced users usually resort to otherwise)
  • Web of trust authentication for additional trust
  • Backward compatibility

Problems/Opportunities for improvement:

  • The additional step when sending an encrypted email of getting the X.509 certificates for the PGP key if Let’s Encrypt Email is supported is necessary to establish initial trust. It could be avoided if the CA would also sign the PGP key but the problem is that the CA then would have to sign the complete identity and therefore be able to verify the users full name, it can’t just sign only the email address part of it as far as I am aware.
  • There are PGP keys uploaded to key servers which the supposed owners do not have control over. If we try to encrypt whenever possible we might often run into situations where the receiver can’t decrypt the email, which harms the user experience dramatically. So we should only encrypt when a trust path can be established, push for encryption subkeys with a relatively short expiration time span and strongly advise users to backup their keys (at least some token to revoke them).

Access from Multiple Clients

Nowadays it is normal to access the email account from multiple email clients and different devices. Many users use web mail interfaces and in some regions often even access them using public computers such as in internet cafés or public libraries. So we need to share the key material in such a way that encrypted emails can be read on multiple clients and the primary key can be shared only among trusted devices.

To reduce complexity and maximise interoperability I propose that Let’s Encrypt Email clients use a Storage API implemented by the email provider with Let’s Encrypt as a fall-back provider, similar to Persona. In that storage they share multiple cryptographic containers containing the key material: one container for the primary key and additional containers for sets of subkeys that are shared by similarly trusted devices. The secret for the cryptographic container limited to trusted devices should in addition to a password chosen by the user also contain a part that is randomly generated and stored on the devices. A new device is marked as trusted by transferring the random secret to the device (via QR-Code, similar machine readable offline channels, or manually).

Advantages:

  • Can use existing credentials
  • Distributed architecture

Problems:

  • Need to roll out a new technology to email providers to take advantage of the distributed architecture and existing credentials
  • Too many eggs in one basket: if the email account gets hacked, the attacker might also have access to the encrypted container with the keys

Advanced users may get additional security if their email client supports storing the keys in a cryptographic hardware device such as a smartcard or USB token (like the USB armory).

Advantages:

  • Totally under the control of the user

Problems:

  • Added complexity of the system limits usability (drivers, limitations of the device, detection in browsers, etc.)
  • No access without the device

Other storage modes such as using IMAP or existing cloud storage providers to store the cryptographic containers would be possible but they all add some layer of complexity or raise compatibility issues. Therefore I propose to limit it to the above choices with the Let’s Encrypt Email Storage API support being mandatory to reach maximum interoperability.

Key Distribution

S/MIME doesn’t solve the key distribution problem. Therefore the most often used method is to send an unencrypted request to communicate privately, which is replied to by a human with a signed message containing the public key of the respondent. This is cumbersome, increases the entry barrier and increases the latency of communication. For company-internal communication LDAP servers can be queried for the certificates but that is no option for external or personal communication because these LDAP servers are often not publicly accessible.

For Let’s Encrypt Email I propose to use the distributed storage API also used for the key storage to store and retrieve certificates. So for every email provider there would be a well-known URL that tells where the certificate for a particular email address can be retrieved. And if the email provider doesn’t provide such a URL, then it falls back to Let’s Encrypt.

Problems:

  • Until email providers widely implement the storage API, Let’s Encrypt will hold a lot of data and therefore be an interesting target for attacks
  • The existence of a certificate can be used by spammers to validate email addresses. Possible solution: always reply with a certificate; if the email address does not exist, generate a certificate on the fly (does not necessarily need to be a valid one, we want to only slow down the spammer).

Email Address Verification

In order to issue a certificate to an email address/public key combination, the Let’s Encrypt CA would first have to verify that the user controls that email address. The usual approach would be to send a verification email with a token that is then send back to the CA to verify the identity, which should be enough for trust on first use and would give a low barrier for the initial set up. The down side is obviously that anyone who can intercept or access emails for that email address can verify that email address as his own.

To make attacks harder, the verification could use Persona instead of or in addition to the verification email. One problem is that Persona’s default password reset process only falls back to a verification email too. But if the email provider has better restrictions in place (two factor authentication, attack detection systems, etc.) then it has higher security properties than the verification email. Especially organisations and users who run their own mail server can implement their own, more restrictive policies.

To avoid taking over email addresses that have existing keys issued for them, we should check PGP key servers, the well-known URLs for public key retrieval and certificate transparency for existing certificates. If an existing certificate is found we could send a verification email that also contains a negative verification link to deny the issuance request. If the positive verification link is followed and the negative verification link is not followed then we could grant the request after some waiting period (one or two weeks).

Account Recovery

When we push for widespread email encryption, we will most likely have to deal with ordinary users who will be more likely to loose access to their private key. Either because they have no backup or because they lost their password. The backup part is partly handled by the storage API, but if the device secret is lost, then it might still happen. The lost password is more problematic and not easily solvable as we can’t just reset the password used to encrypt the cryptographic container. One solution is to encourage users to print out the full secret for the encrypted container and store it some place safe. But even then we have to expect that some users do not follow the advice. In that situation the user can just generate a new set of keys, the process for email address verification with existing keys would also handle the case when access to the private key is lost and the old key would be revoked.

If you like the proposal, then I would be happy to work with you to realise such a system. If you have suggestions on how to improve, I would be happy to know.

16 Likes
2

I think this is great idea. Merging PGP and S/MIME together could really solve a lot of issues and finally create a good solution to e-mail encryption. PGP’s web of trust removes problem with untrusted authorities and S/MIME support is already everywhere.

Since S/MIME does not address key distribution, we can use existing PGP tools. A PGP key can contain photo of owner, it should be able to contain S/MIME cert too. PGP key management tools will have to be updated to support this, but it should be relatively easy. Then we can use PGP to build web of trust plus to distribute keys, and S/MIME to actually encrypt and sign everything. (You wrote this somewhere in middle, but i think this is the key feature.)

I would not bother with multiple clients support. It is easy to copy encrypted container to all two or three devices user is actually using. And for security reasons it is better to keep private keys separate from mail server.

1 Like
3

CAcert offers the service of signing OpenPGP keys after the user reaches a certain amount of points. The signature is valid for six months each time.

2 Likes
4

but CACert is not really trusted yet, sadly…

5

They are working on it.

1 Like
6

well that’s nice because I am also registered there and because of face-to face validation for certs longer than 6 months and/or class-3 certs with the one who gets the certs they could be trusted a lot more than LE

1 Like
7

@Svavar_Kjarrval: To sign PGP keys one has to verify the name of the person because one can’t sign only the email address of an identity, that’s a technical restriction by the PGP key format. So unless we build some kind of name verification (for example by using electronic passports issued by some governments) we can’t sign PGP keys. CAcert solves that problem by having a web of trust of so-called Assurers checking the government issued IDs. So in order to get a signature on your PGP key you have to meet at least two Assurers in your area to get your identity verified, so there is a delay and an additional barrier that users have to tackle in order to start using trusted communication.

Also PGP traditionally has no set of built-in trust anchors like CAs. So even if one day CAcert passes an audit and becomes included in the major browsers, that will have no effect on the trust that is per default assigned to PGP keys signed by CAcert. Users will still have to manually import the PGP key of CAcert. That would be the major advantage of Let’s Encrypt Email.

1 Like
8

S/MIME and PGP is… PGP/MIME? This already exists, and it’s a disaster. I’m not sure what you’ve proposed solves the mess of envelope formats.

I’m not sure it solves the issue of key distribution and trust either. Why would Lets Encrypt do this better than say… Keybase? Or Facebook, which recently started letting you associate a PGP key with your account?

I’m imagining a UI that, once you receive a message with a key you’e not seen before, pops up a window that lets you verify that someone is actually your friend on Facebook. You don’t get better UX for key verification for your average Joe, who spends most of their time on Facebook already, than that.

Google is working on UX, key distribution, and maybe even envelope formats with their end-to-end encryption project:

Not sure what role Let’s Encrypt has here.

1 Like
9

interesting proposal

for encrypted emails I just use https://www.sendinc.com/ and have less headaches :slight_smile:

10

@eva2000: Sendinc does not use end-to-end encryption and when I read their description of how it works, it’s wrong on so many levels:

  • They receive your message in plain text ⇒ An attacker on their server can read your message
  • They send the encryption key by email to the recipient in plain text ⇒ any attacker who can read or intercept the email they send to the recipient can read the message
  • They store the encrypted message in the Amazon cloud ⇒ any attacker who can guess the link to the encrypted message (by brute force or because they leak the locations of the encrypted messages somehow) and has enough resources to break the encryption can read the message even if they start the attack long after the message with the link has been sent and maybe even deleted from the recipients inbox.
  • They say they use a “military-grade” encryption algorithm, but don’t state which one exactly, in which mode of operation and do not publish their source code ⇒ snake oil sellers often use such terms to lure customers without providing any real security. Not only do you need to know which exact algorithm they are using, you also need to know which mode of operation they are using it in to evaluate if it could be secure (and that still ignores any vulnerabilities in the implementation they use). They could for example use AES but in Electronic Codebook Mode which is very weak.

So in summary you might as well just send the message in plain text to the recipient and hope that your email servers have transport encryption enabled. The only thing you gain by using Sendinc is, that if your own email server is compromised and Sendinc isn’t and their “military-grade” encryption is holding up for years to come then you are safer than just sending the email in plain. So instead of using Sendinc you could move to an email provider with decent operational security and would be better off, because it would be more convenient and wouldn’t give you a false sense of security.

3 Likes
11

@tamasrepus: No PGP/MIME is not S/MIME and PGP combined, it essentially only detaches the PGP signature from the email body text into a separate MIME part instead of sending it inlined in the body. It has nothing to do with S/MIME except that they are both based on MIME and the MIME security multipart type (RFC 1847). I don’t know why you think it’s a disaster, it lets you encrypt/sign attachments and such stuff.

AFAIK Facebook only uses the PGP key to encrypt the emails they send to you, they don’t have an API for other users to verify your key.

Keybase is indeed an interesting project. It’s essentially a decentralised identity verification scheme that uses existing public records with a centralised index to all those identity proofs. The system relies on the assumption, that you know at least one identity of a person with an associated public record of her PGP key. The more identities you know, the better. When we look at email there is the unfortunate situation that there is no public proof of your email address. So if you only know someone’s email address and maybe phone number, which might be the case with business contacts for example, you are out of luck.

Also even if Facebook provided an API and if Keybase provided some way to link email addresses then you still have the problem that such a system would need wide adoption and installing add-ons to your email client. Let’s Encrypt Email would be fully compatible with S/MIME which is built into many email clients by default. Also Let’s Encrypt Email doesn’t restrict additional ways to verify an identity. If you have an add-on in your client that can additionally verify the key via Keybase, that’s good. And Keybase could use the mechanisms provided by Let’s Encrypt Email to have public proofs for email addresses. That’s a win-win.

I did know about the Google End-To-End project, but I didn’t know about their approach to key distribution. Thank you for pointing that out to me. So far the e2e key distribution scheme is only a proposal and not yet implemented so I’m not quite sure about some details. The scheme is essentially a set of registration services with public audit logs that store the history of email address / public key pairs. They call those systems key directories. The users gossip about their view on the logs to make sure that they see the same thing, so any malicious key directory would be detected. I like the idea and in some way it is very similar to my proposal. Just think of the key directories as being Let’s Encrypt Email compatible CAs which take part in Certificate Transparency. Instead of naming one identity provider (Persona in my proposal), they leave that choice open to the key directory. The key distribution is also handled by the key directories: they store the keys and users can ask their local key directory for the key for other users (how the local key directory finds the key in the remote directory is unclear to me). In my proposal that is replaced by a distributed storage, potentially at your own email provider, with a fall-back to the Let’s Encrypt server. What the e2e proposal lacks is compatibility with any existing tool. Neither S/MIME-compatible email clients nor such that support PGP will know how to query key directories by default. So I think there’s potential to merge those two proposals to get a system that is secure and usable.

Why should Let’s Encrypt be the right place to push Let’s Encrypt Email? I think with Let’s Encrypt we have organisations we need to successfully launch such a project already working together. Mozilla develops a major email client and could therefore lead on that front. Let’s Encrypt itself operates a CA so it can provide the entry point for users who do not have access to a commercial CA. I think the email providers might get on board if they see that integrating our solution is a lower effort and more convenient for their users than providing their own. And last but not least: The mission of the ISRG is “to reduce financial, technological, and education barriers to secure communication over the Internet.” Email constitutes a significant portion of the internet communication, especially the portion where users feel an urgent need for protection, because they send very private information to their friends and family, in many cases completely unprotected or only dangling on the thin string of server-to-server transport encryption. I think it’s time to change that.

2 Likes
12

@NEOatNHNG: I mentioned CAcert because when it signs OpenPGP keys it’s kind of working like a CA for e-mail encryption keys. In the future, software might support a function like this. I wasn’t rejecting your idea outright so I don’t know why your arguments were put forth like I were.

Sure there is the problem of the name field in OpenPGP but would it hurt so badly to extend a working standard instead of creating a new similar standard? Let’s Encrypt could sign OpenPGP keys and whoever accepts the LE signature is (presumably) going to know LE doesn’t verify the name, only the e-mail address. The sender isn’t going to be presumed trusted or half-trusted anyway unless the receiver has considered LE a trusted entity.

13

?? https://www.sendinc.com/product/how-it-works

How Sendinc Works
Sendinc secures your message by ensuring that your data remains encrypted from the time it leaves your computer through the time your recipients retrieve it. At no point in the process is your message data transmitted or stored in an unencrypted format. Sendinc further ensures the safety of your messages by verifying your recipients are in fact your intended recipients.

14

but it is at no point unencrypted but it is for a time encrypted in a state that they can read it (their encrypted file systems, RAM) and the link that has to be sent is there as well...

Our servers temporarily store your message on an encrypted file system while they await further processing.

as there is seen. well it's not just the link but the key could also be read out while it is used for encryption.
also since it is sent "just" via SSL/TLS in the case of heartbleed v2 or some other serious bugs, new messages could be intercepted. and keys and stuff in the RAM of the server could be read out as well...

also they still just say that the mails are stored with military encryption, without saying what is used.
and still the link is still emailed, making it rely on a server-to-server encryption.

15

I guess i understand where you’re coming from… it’s the same as saying SSL/HTTPS covered web site wouldn’t be secure if servers involved are compromised/MITM’d

16

the point of this proposal is making and to end with realtively easy key distribution, certifivation etc.
and the website is everything but end to end and anyone with access to the emails of the user can access the emails, a point which is negated when using end to end encryption, depending on how it’s done…

17

I have heard about 2 or 3 years ago that CACert was working on becoming trusted, that is quite a long while to becoming trusted.

18

Building bridges between S/MIME hierarchical trust and GnuPG web of trust seems very interesting. The first one is usually supported by governments and their structures, and sometimes embedded on the identity documents of the citizens (ID card or passport, etc.). If we could use a S/MIME certificate (issued by government) to sign a GPG certificate, this would certainly boost the trust of GPG certificates. On the other hand, the GPG certificates are more flexible and handy and more suitable for everyday use.

Regarding encrypting emails, actually I think that it is not a good idea to encrypt all the emails that are sent and received. Maybe we can encrypt the ones that we can afford to delete just after reading them (including secret/private messages). However nowadays people usually save their emails, so that they can search them later and find the information that they need. Encrypting all of them makes this difficult. And if the private key is lost, then all the encrypted emails are lost as well (which could be a disaster for most of the people).
The goal should really be end-to-end encryption (sending and receiving them in an encrypted way), rather than encrypting all of them and keeping them encrypted.

Signing emails, on the other hand, is quite a different story. It does increase the security of the internet (because no body can fake emails from your address or modify the content of the emails while it is in transit, or later, after it has been saved). It also has no downsides; if you loose the private key, then the public key most probably is still there, on some key servers, and still can be used to verify your signature.

Regarding sending and receiving private emails, what do you think about these other options:

1 Like
19

@dashohoxha: I aggree. Securing all the way e-mails travel is very important. And when the path is secure, signing is the priority. But signing and encryption is almost the same.

I noticet little detail you wrote: “If we could use a S/MIME certificate […] to sign a GPG certificate, […]”. I didn’t realize this, but it may make all this much easier to implement. It is not neccessary to have same key in S/MIME and PGP format, instead we can let one key sign the other and vice versa, and distribute them together. So we can reuse existing keys from different sources for this purpose.

1 Like
20

Ensuring the readability of end-to-end encrypted email is indeed a major concern. That's why we have to take care of key recovery/backup. A solution would be to decrypt encrypted emails when fetching them and storing them unencrypted. That is a good option if they are stored on your computer, but not when they are stored on a server that is not under your control (e.g. IMAP access to GMail, Webmail interfaces) because we know about surveillance programmes like PRISM where agencies have access to data stored on those servers. Own-Mailbox and similar projects like FreedomBox provide a great approach to solve this problem of storing the decrypted email because they place the control over your data back into your hands. Such projects provide a good complement to an initiative like Let's Encrypt Email. I haven't tried them myself yet, so I don't know about the quality of implementation and usability of those projects.

Only encrypting the emails that contain very sensitive content is not the solution because it increases the complexity for the user, who then has to decide for every email whether it needs encryption. Also it signals to attackers which emails might contain valuable content, so they can focus their attacks on that subset.

DMail seems to be better than Sendinc in the way that the content is encrypted in your browser, so they don't get the plain text (unless an attacker modifies the JavaScript) and their marketing is more focused on the ability to be able to delete email and uses less Snakeoil terms. Otherwise the approaches look pretty similar to me, so there are similar problems.