diff options
Diffstat (limited to 'content/entry/re-dkim-show-your-privates.md')
| -rw-r--r-- | content/entry/re-dkim-show-your-privates.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/content/entry/re-dkim-show-your-privates.md b/content/entry/re-dkim-show-your-privates.md index 36a9e6a..7176843 100644 --- a/content/entry/re-dkim-show-your-privates.md +++ b/content/entry/re-dkim-show-your-privates.md @@ -4,7 +4,7 @@ date: 2023-03-15T00:00:00 tags: ['computing'] draft: false --- -I recently read Ryan Castellucci's blog post, "[DKIM: Show Your Privates](https://rya.nc/dkim-privates.html)". The problem Ryan points out is that DKIM, which signs outgoing emails as a way to to reduce spam, has a negative unintended consequence: it's harder to deny that you sent an email if it gets leaked. As Ryan points out, saner messaging protocols like [OTR](https://en.wikipedia.org/wiki/Off-the-Record_Messaging) and the [Double Ratchet Algorithm](https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm) do implement cryptographic deniability of messages. +I recently read Ryan Castellucci's blog post, "[DKIM: Show Your Privates](https://rya.nc/dkim-privates.html)". The problem Ryan points out is that DKIM, which signs outgoing emails as a way to reduce spam, has a negative unintended consequence: it's harder to deny that you sent an email if it gets leaked. As Ryan points out, saner messaging protocols like [OTR](https://en.wikipedia.org/wiki/Off-the-Record_Messaging) and the [Double Ratchet Algorithm](https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm) do implement cryptographic deniability of messages. There is a way to mitigate the loss of cryptographic deniability in email. You simply rotate DKIM keys, invalidating the old one and publishing its private part. The point of publishing the private part is that any leaked emails which were signed with that key could be forged. Thus, one can deny past emails signed with that key. @@ -18,11 +18,11 @@ The Session team's blog post, "[Session Protocol: Technical implementation detai > > Instead of designing a cryptographic protection, Session will add the ability to edit other users’ messages locally, thus providing a way to completely forge conversations. Since signatures are deleted after messages are received, there will be no way to prove whether a screenshot of a conversation is real or edited, diminishing the value of screenshots as evidence." -Programmers could still change the Session source code to save the message signatures anyways, but I highly doubt anyone is doing this. By contrast, email servers *do* retain email signatures even after emails are already validated. So there's more of a concern for email being cryptographically undeniable than Session Private Messenger. +Programmers could still change the Session source code to save the message signatures anyway, but I highly doubt anyone is doing this. By contrast, email servers *do* retain email signatures even after emails are already validated. So there's more of a concern for email being cryptographically undeniable than Session Private Messenger. So, in my opinion, all email providers should publish expired DKIM keys. Especially the big ones that handle lots of mail like AOL, Gmail, iCloud, Outlook, Yahoo, Yandex, etc. I'll quickly debunk some of the main objections. -Publishing expired keys doesn't make spam harder to combat since the key gets revoked anyways. Since email accounts rely on the security of both client *and* the server and many people use weak passwords and fall victim to phishing attacks, determining whether someone sent a particular outgoing email depends more on context (server logs, IP addresses, other info) than DKIM signatures. So publishing expired keys probably doesn't make computer forensics harder. +Publishing expired keys doesn't make spam harder to combat since the key gets revoked anyway. Since email accounts rely on the security of both client *and* the server and many people use weak passwords and fall victim to phishing attacks, determining whether someone sent a particular outgoing email depends more on context (server logs, IP addresses, other info) than DKIM signatures. So publishing expired keys probably doesn't make computer forensics harder. This practice could make valuable corporate/government email leaks less credible, but CEOs and politicians aren't the only ones who use email. Everybody uses it and making everybody less safe to gain slight confidence that occasional, albeit important email leaks are legitimate doesn't seem worth it. |