# Deprecation of RSA-SHA-1 in DKIM keys?

I recently noticed that OpenDKIM on my mail server is objecting to DKIM signatures from a client, saying their key is insecure. It may be that that's due to lack of secure DNS (confirmation anyone?) but I also noticed that the signing algorithm is shown as a=rsa-sha1, and with the move to “Deprecate SHA-1” in other contexts, I'm wondering: how urgent this is for DKIM?

It is now feasible to brute-force SHA-1 hashes. Am I correct in thinking that this would need to be done for each message an attacker wished to forge the signature for, without being able to re-use that work for the next message?

• The feasible attack against SHA-1 is a collision attack, not even a chosen prefix attack, let alone a second pre-image attack. – CodesInChaos Sep 23 '14 at 15:36
• Maybe this? Otherwise, what's the RSA key size? DKIM allows 512 bits which is insecure, though I don't know if OpenDKIM checks that. – otus Sep 24 '14 at 6:56
• Thanks for that link @otus. It provides confirmation that the opendkim warning is almost certainly about DNSSEC. The key in this case is 1028 bits, so presumably secure, but I'm still interested to know if there's any move to replace sha-1 here. – mc0e Sep 24 '14 at 23:05
• For anyone curious, SHA-1 in DKIM has now been deprecated in RFC 8301, and is now listed as "historic" in the IANA registry. – lime Dec 4 '18 at 4:25

It may be that that's due to lack of secure DNS (confirmation anyone?)

So it turned out to likely be a warning about lack of DNS security.

I also noticed that the signing algorithm is shown as a=rsa-sha1, and with the move to “Deprecate SHA-1” in other contexts, I'm wondering: how urgent this is for DKIM?

Not very urgent. Current attacks only put a dent in SHA-1 collision resistance, which requires generating a large number of messages to find a pair with equal hash values. That is only a concern whenever the attacker can both predict the data to be signed and influence some of it.

Typically, with DKIM an attacker can't get such a message signed. If you send an arbitrary message that gets signed by the domain, the attacker would need a second preimage attack to forge a change. The second preimage resistance of SHA-1 is still close enough to the expected $2^{160}$ to be completely unbreakable with current attacks.

There may be special cases where a collision attack could be possible, like if the attacker has access to an email account on a domain, but the messages are screened for spam before being sent. Then they could look for a pair of messages where one is innocent, the other spam; send the legitimate message; and copy the signature to the spam message. In this case the attacker would have to predict any header fields and the like that DKIM signs, so feasibility would depend on the setup.

Even if a collision attack was possible, it would take quite a lot of computational effort ($2^{61}$ or so).

Am I correct in thinking that this would need to be done for each message an attacker wished to forge the signature for, without being able to re-use that work for the next message?

Finding multiple collisions is not that much harder than finding one. A generic preimage attack also becomes easier the more target messages you have. So the attacker could probably share some work if an attack was possible in the first place. However, it's not a key recovery attack, so every new forgery would need more work, yes.

• I'll need to do a bit of work to fully understand some of what you've said, but I think you've answered my question. Unless someone starts poking holes in what you've said I'll mark it correct in a few days time. – mc0e Sep 25 '14 at 12:41