🔐 Every unencrypted email is readable by 10+ entities and stored forever.

[thedarktangent@defcon.social]

@nicfab @yawnbox An article about email security, but no mention of S/MIME?

[nicfab@fosstodon.org]

@lennybacon 1/6
Your analysis hits the nail on the head. The fundamental architecture of email predates modern cryptography, and what we do today is essentially retrofitting security onto a protocol from the 1970s.

[nicfab@fosstodon.org]

@lennybacon 2/6
The lack of PFS is indeed critical: every encrypted email becomes a time capsule waiting for quantum computers or a key compromise. Unlike Signal or Matrix, which utilize double-ratchet algorithms to ensure both forward and backward secrecy, email encryption remains static — a single key leak compromises entire email histories.

[nicfab@fosstodon.org]

@lennybacon 3/6
And metadata exacerbates the issue: even with PGP/S/MIME, headers expose communication patterns, timestamps, and relationships that can be more revealing than the message content itself. WKD is pragmatic incrementalism: it solves the decades-old “chicken and egg” of key distribution, but it’s still polishing brass on the Titanic. Real progress requires a protocol redesign.

[nicfab@fosstodon.org]

@lennybacon 4/6
Possible directions include:
• MLS (Messaging Layer Security) for federated asynchronous messaging with PFS
• Post-quantum key exchange (already in TLS 1.3 trials)
• Encrypted headers and padding to mitigate traffic analysis
• Ephemeral identities to reduce long-term correlation

[nicfab@fosstodon.org]

@lennybacon 5/6
The hard part is backward compatibility: email’s universality is both its strength and its prison. Perhaps the way forward is dual: incremental improvements (e.g., WKD, Autocrypt) to make current email “secure enough,” while simultaneously building truly secure alternatives that could eventually replace SMTP.

[nicfab@fosstodon.org]

@lennybacon 6/6
So the real question is: migration by evolution or by revolution?

[nicfab@fosstodon.org]

@tudobem @PierricD It depends on the provider you chose. You can check Netcup or Contabo, which are more affordable options.

[nicfab@fosstodon.org]

@thedarktangent @yawnbox This article is not about email security but about WKD. I have already written about email security and will likely revisit the topic in the near future.

[nicfab@fosstodon.org]

@delta @Blort 1/3 - Absolutely right — IETF standards aren't automatically the best fit for every use case. DeltaChat is actually a great example of this nuanced approach: it leverages email infrastructure creatively while adding features like Autocrypt and ChatMail servers to address some of email's inherent limitations.

[nicfab@fosstodon.org]

@delta @Blort 2/3 - WKD solves one specific problem (key discovery), making traditional email encryption more accessible. However, as you point out, true resilience requires more: forward secrecy, metadata protection, and decentralization without single points of failure.

[nicfab@fosstodon.org]

@delta @Blort 3/3 - That's why I see WKD and projects like DeltaChat as complementary rather than competing — WKD improves the email baseline. At the same time, Delta pushes the boundaries of what email-based messaging can achieve. Different tools for different threat models and use cases.

[thedarktangent@defcon.social]

@nicfab @yawnbox I have lived through essentially the same issues with PGP keys in DNS, hashes of SMime keys in DNS, MTA-STS, DANE for SMTP, automatic SMIME using SMILE, etc.

I hope WKD does better! But I fear that without a solution to local email search it will be a victim of its own success, or you will have to put so much information in the subject line to remind you what is in the encrypted body that some privacy is lost.

[tudobem@social.tchncs.de]

@nicfab @PierricD thank you! would it be okay if I get back to you with questions in case they come up along the way?

[nicfab@fosstodon.org]

@thedarktangent @yawnbox I share your concern — past attempts (PGP in DNS, DANE, SMILE, etc.) struggled with adoption. WKD isn’t a complete solution, but it’s worth setting up: it removes a key barrier and makes encrypted mail more usable, even if challenges like local search and subject-line leaks remain.

[nicfab@fosstodon.org]

@tudobem @PierricD Of course, feel free to reach out anytime.

[grant_h@mastodon.social]

@nicfab
Reading the article, I can't see how this works out in a hybrid situation - where not all your email recipients are using WKD. Am I missing something?
You mention the strength of email being its own prison - we need something that would encrypt where possible, and fall back to plaintext where not (with warning). HTTPS was not implemented across the board overnight.

[nicfab@fosstodon.org]

@grant_h 1/2 You're right — WKD alone doesn't handle the hybrid scenario. It's just key discovery, not the complete solution.
For opportunistic encryption, you need WKD plus smart clients: Thunderbird, DeltaChat, and others already do this — they check for keys via WKD/Autocrypt, encrypt when possible, and fall back to plaintext with warnings.

[nicfab@fosstodon.org]

@grant_h 2/2 - Think of it like HTTPS adoption:

- WKD = certificate infrastructure (like Let's Encrypt)
- Autocrypt/client logic = protocol negotiation
- Warnings = mixed content alerts

So yes, the ecosystem supports "encrypt when possible" — WKD makes finding keys automatic. The clients handle the graceful degradation you're looking for.

[grant_h@mastodon.social]

@nicfab My use case is a school. Teachers and students. Particularly the counselling staff. It has to be easy and seamless, and resetable by our admins.
Unfortunately, the big companies have no incentive to make our email private, and every incentive to make it easy to join. The precise opposite of so many FOSS projects. We will persevere!