Understanding Email Encryption
fastmail.com>OpenPGP uses a decentralized “Web of Trust” where users vouch for each other’s keys.
This article fails to mention WKD [1] (Web Key Directory) which is supported by Proton Mail, doesn't rely on the "Web of Trust" and allows seamless PGP encryption of sent emails. Here is an example of how this works (and how it can get annoying) [2].
[1] https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
The article on end to end email encryption:
>Contrast all this with Signal or WhatsApp, where encryption works automatically because a single organisation controls the full software stack rather than using open protocols.
In a usability study involving Signal[1], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection. There seems to be a tradeoff. We can do either usability or security, but never both at the same time.
[1] When SIGNAL hits the Fan: On the Usability and Security of State-of-the-Art Secure Mobile Messaging https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...
> Additionally, servers don’t verify certificates by default. […] This is because verifying the certificate adds no security when an active attacker could just fall back to an unencrypted connection.
But surely the eventual goal is encrypted-only, at which time that’s no longer the case. Not verifying certificates feels like it may just slow down the process, because now when it looks okay you may actually find it’s not, the error is just masked for now.
I self-host my email, in part because I wanted to enforce encryption whenever I send. My server does verify the certificate of the target MX, whether it uses MTA-STS or not. Delivery fails if the certificate is invalid, and also fails if the destination (or a man in the middle) downgrades or strips STARTTLS.
In eight years, I’ve seen zero servers that refused STARTTLS, and only two invalid certificates. In both cases, the certificates were from a valid CA and weren’t expired, but the hostname was wrong. Both were due to outdated DNS records, one of which was fixed as soon as I reported it, and the other resolved itself after a few months.
> My server does verify the certificate of the target MX
But how do you know if the target MX is correct, and not controlled by an attacker? You can't really know for sure unless the receiver has secured their domain name with DNSSEC or published an MTA-STS policy.
I am self-hosted: minimal smtp server, no TLS, only direct and basic delivery of emails. I don't even pay the DNS mob, namely I use IP literals (mailbox@[x.x.x.x] and more mailbox@[ipv6:...], see smtp RFC, yeah the email guys were smart enough not to make their protocol hard dependent on DNS neither on any crypto).
I do not trust the CA system. If I ever crypt the content of an email, it would be because a guy I saw gave me its public key in some way (QR code?) face to face. For really serious stuff, I would not use smtp anyway and with some modified-standard-cipher pre-shared key anyways.
Temporary states go on with a long tail. Look at the v6 transition. We're dual stack for the foreseeable future and it's my guess we'll be in partial deployment of secure mail transport for aeons.
Google is easily in a position to force it unilaterally.
They already do, but unfortunately only for mass senders.
That indicates that they require it for all inbound mail, but it doesn’t yet cover outbound.
Google blocks IP literal email addresses (which is stronger than SPF and should be part of DMARC).
I just had my first foray into S/MIME. Tons of mail providers and software hide it behind enterprise licensing and I didn't want to do that for ~2 emails a year. I'm extremely thankful to the Thunderbird team and the OpenSC projects.