As you may have seen, either via the US-CERT alert or the story in Wired Magazine , a configuration error in DKIM signing implementations was publicized the week of October 22, 2012.
This is NOT a weakness in the DKIM specification or the DMARC standard. This is solely a potential problem in how specific companies have configured their DKIM signing implementations, and even in those cases with a vulnerability, remediation is simple. The same issue would apply if HTTPS certificates used weak public keys.
The root issue is that some companies have configured their DKIM implementations to use public key lengths that are too short (512 or 768 bit key lengths when 1024 bit keys are the minimum and 2048 is even stronger). We did an informal survey of current DKIM implementations and found that 18% of the time, the DKIM signature was too short.
This is a known issue and in fact the DKIM RFC standard states, “Signers MUST use RSA keys of at least 1024 bits for long-lived keys”. While 512 bit keys were strong enough 10 or 15 years ago, today a 512 bit key can be cracked using a desktop PC in hours, while a 768 bit key can be cracked using little more than $100 worth of cloud computing time. In fact, VeriSign no longer even issues 1024 bit SSL keys, requiring instead a minimum key length of 2048 bits. Our survey showed only 4% of users were using key lengths of this size, while 78% use key lengths of 1024 bit.
All DKIM keys should be a minimum of 1024 bit, and Agari recommends that all its customers use 2048 bit keys if adequate processing capacity is available on the customer’s email infrastructure. 1024 bit keys are secure against all but the most sophisticated attackers today, while 2048 bit keys are secure against all attacks for the foreseeable future.
So, what can you do?
Check your DKIM key strength. If you are an Agari customer, we are doing this for you, look for an email from customer support.
Not an Agari customer but need help? Contact us at firstname.lastname@example.org.