An important thing to realize is that, with email, it is not possible to establish Forward Secrecy.
This means that if the key is ever compromised down the road (even years later) the email can be decrypted.
Transport
The TLS protocol used to exchange mail between properly configured mail servers does support forward secrecy, meaning that your communications should be reasonably secure outside the situation of a compromised Certificate Authority (CA). Checking CAA records helps mitigate this since not any CA will be trusted for the respective domain, but it requires the remote party to enable such records in their DNS and have a known set of CAs.
At this point there are two threat models worth considering:
- one of the two parties cannot trust the mail provider (encryption at rest can mitigate risk)
- one of the two parties cannot trust their own organization IT / administrators (encryption can mitigate but only with stringent key control / HSMs. Otherwise theyâd just pull the key from your machine)
It comes down to the threat model, as encryption is inherently inconvenient for anything other than ephemeral messages (in which case go to Signal).
Identity & Non-Repudiation
There are two important functions provided by key validation.
- you know the key is the correct key to encrypt a private message
- a message you receive you can verify is authentic and could only have been sent by the claimed sender (non-repudiation)
If we want to go down this rabbit hole the first problem is schemes like PGP have a key distribution problem. You can upload keys to a system such as Keybase or the MIT SKS server, but we have to establish the key is actually belonging to the party you desire. Keybase doesnât do email validation, but offers some form of trust validation through verifying a key is possessed by the same person as, say, a github or twitter account. This is assuming you trust Keybase in your threat model (which, for a typical user without nation state level attacks, you probably wonât have much better). The traditional SKS servers, like pgp.mit.edu, are great in simplicity and automation but provide zero validation so anyone can upload a key claiming it belongs to the email stated.
Practical Usage Problems
Remote Party Implementation
Beyond key distribution problems, we run into the implementation on the receiving as well as the sending end. This requires configuration of reasonable ciphers for the threat model, and all parties agreeing to the encryption choice used. Many professional orgs will not use PGP but instead use S/MIME (which does not have an easy way to handle outside of the org for encryption in practical manners) but is very common and effective for internal org usage. Other orgs will enforce PGP very rigorously for external usage, but ciphers and key support may be limited to traditional RSA and CBC algorithms. These ciphers are fine for the typical threat model.
Key Management
An encrypted PGP key with a strong password can be treated like an encrypted file and shared across devices. PGP does not support ephemeral modes by nature so the keys can be simply shared as-is. Solutions such as Keybase can help with this, but only if you trust Keybase to do primary key management as well as identity validation. The typical PGP users probably donât do this, but there arenât good statistics to match.
Long-Term Message Storage Security
This is where services like Protonmail provide some value; in reality they can alter their codebase and view your email anytime they want (they would just need to alter their client-side javascript to send the key off on decryption for whatever user they desire). The fact they are in Switzerland lends some privacy laws, but youâre still placing a not of trust in the service to not be evil.
Services like G Suite, itâs free counterpart Gmail, and similar competitors donât have the encryption at rest that ProtonMail / Lavabit provide, but in the end if you are encrypting your mail separately it may not be considered a risk in the threat model.
The Mail Server
When running your own mail server you can, of course, encrypt the disk yourself however a mail server has to inherently be able to decrypt to operate. Unless you are shelling out a lot of money on HSMs and boot integrity modes this is quite a significant problem from a practical perspective to prevent complete access by a NOC tech in a datacentre environment. You can make it take more effort, but itâs going to be possible. Even more so with a VPS, since the host organization can choose to dump the memory.
Running mail at home is a bad idea for professional work since it will often trigger common spam filters due to the IP ranges home ISPs own, if your ISP even leaves port 25 available without cutting your service.
Lastly, you of course need to be comfortable configuring the main server and maintaining it from a security and operational perspective.
DKIM/SPF/DMARC
Iâm not going to make this yet another spiel about it since itâs been linked to a lot above, but if youâre running your own mail server you need this.
DKIM generate RSA keys with at least 2048 bits of entropy. This requires a DNS provider with Multi-Line UDP response (for example Namecheap does not support this)
