Hacker News new | ask | show | jobs
by bjornedstrom 2045 days ago
As a security professional I 100% agree with the author.

The comments here on Hacker News seem to have tripped on the examples given (keywords: politicians, journalists) and turned this into the more generic and politically loaded discussion whether it's desirable to "cryptographically verify" what politicians write.

But that's not the point! The point is that DKIM is technically not designed for this use case and the way people misuse DKIM for this unintended purpose is highly problematic from a cryptographic and engineering perspective.

I think the best way to think of DKIM is that it's a "cryptographic protocol" in the sense that git is a "cryptographic protocol" because it uses SHA1. If you think "PGP" (not the best example :-)) or "Telegram" you have the wrong idea: DKIM is a bunch of cryptographic primitives haphazardly bolted on email to solve a specific problem. It's not good cryptographic design because good cryptographic design anticipates unintended usecases and deal with them appropriately.

1) Read the DKIM RFC.

First of all the only field that it's required to sign is the From: header (see RFC, section 5.4). So you could still forge an email but have it pass a DKIM signature check.

If people believe that DKIM "cryptographically signs" e-mails in the sense of PGP, then that's a problem, because that's not true. A DKIM signed email doesn't actually say anything: you have to look at the signature which part of the message are signed, which is not standardized.

So you could have this situation when people, like journalists or even people on Hacker News, think a forged email is valid because it has a valid DKIM signature (but the signature is over the From: header only). E-mail is complicated as it is without having to explain to people who have binary classified an email as "forgery" or "not forgery" based on a specific combination of email-headers and DKIM signature specification. Let's not do that.

2) Look at what mail providers actually do with their DKIM keys.

For legacy reasons due to DNS providers and length of TXT records, many large internet providers use DKIM keys that are 1024 bit RSA.

Already 10 years ago, most standard bodies started to recommend against the use of 1024 bit RSA. It's deprecated. Like MD5-deprecated.

The fact that many service providers use the same key for all emails for all customers and reuse that key for years, increasing the likelihood of the key being leaked, is another case against trusting DKIM for this purpose.

2 comments

> 1) Read the DKIM RFC.

> First of all the only field that it's required to sign is the From: header

OK, I've never looked into DKIM before, but 6376 looks fairly recent, and it reports the message body must be hashed. Now sure, there may be issues with the hash to allow arbitrary collisions, and of course the key may have been leaked or broken, and in any case today's key is unlikely to be secure against nation states now, let alone in 10 years time.

I agree in general the idea that having "DKIM signed" mails means they are authentic is an issue -- in 20 years time it will be easy enough for anyone to forge a DKIM signature for any email they want that they claim was sent today, but from what I can see the message body is signed.

Technically, DKIM probably shouldn't take away deniability. But to be fair, this discussion doesn't exist in vacuum. Requesting that Google publish private keys is inherently politically loaded, given recent events. (and it's was neither goal or anti-goal in DKIM design, so it's not that there is mistake in protocol or something).

If some provider decides to implement this proposal, I don't think they should do it retroactively and publish old keys. It would be just inviting additional political shitstorm.