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

[delta@chaos.social]

@Blort @nicfab we know about wkd and some of us have engaged with it in earlier times. Our current trajectory of #chatmail developments is not directly fitting as we are aiming to hide all cryptographic identity information from the transport layer (email servers). Wkd rather reinforces the central role of email servers in managing and controlling a users cryptographic identity. Besides there are error cases (wkd down/erroring), stale keys and other issues that cause UX challenges.

[pierricd@mastodon.green]

@nicfab I did not know of this, and find it fascinating. I use proton with a custom domain, so I don't benefit from it based on the article. Next project: setting up my wkd server!

Only downside: I make extensive use of catch-all addresses, and I suppose wkd doesn't account for a "default user inbox" if it relies on username hashes like the article explains. But still worth setting up!

[nicfab@fosstodon.org]

@delta @Blort I won't go into technical details here. There is an IETF draft that I referred to. I appreciate your work, but standards must be respected. If any WKDs are not working, there may be misconfiguration issues.

[nicfab@fosstodon.org]

@PierricD You can set up WKD with your domain name even if the MX records are on Proton. You need a server.

[delta@chaos.social]

@nicfab @Blort we know there is an IETF doc about wkd. Delta is probably one of the most standards based messengers out there https://github.com/chatmail/core/blob/main/standards.md
But that doesn't mean any IETF standard is unconditionally a good idea for resilient decentralized messaging.

[tudobem@social.tchncs.de]

@nicfab @PierricD what would the average annual server cost be if one were to set up a server simply for WKD? I‘m not a tech guy unfortunately, so I find it difficult to assess

[lennybacon@infosec.exchange]

@nicfab I appreciate every attempt to make the web more secure by default.

What is your opinion on if I would state: Isn’t encrypted mail also stored forever and readable in the future? As e-mail lacks PFS…

I’m more concerned about that and things like headers being not encrypted and therefore, leaking meta data, than getting my keys to ppl.

If things must change it is probably SMTP that needs a successor with things like double ratchet session keys and key exchange parameters. And while we’re on it, probably some post quantum ability would fit the timeline we are in.

What do you think?

[micha@23.social]

@nicfab @koehntopp Sounds too good. Hope it's not. 😃👍

[nicfab@fosstodon.org]

@micha @koehntopp Why not?

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