On Wed, May 13, 2015 at 01:21:36PM +0800, Roland Turner wrote: > (e.g. perhaps measurement discovers that 512 bit keys are only used by > low-risk domains; does this warrant killing the feature for the good of those > who are being targeted, or retaining it because it's still in use, with a > clear > understanding that highly-targeted organisations aren't going to use 512 bit > keys to begin with?)
I did some measurements this morning. In a corpus of emails sent in the past three weeks, I found ~400 different DKIM selector-domain combinations used to sign legitimate emails. (This is out of ~11k such emails.) Out of these, three used a 512-bit RSA key. A further seven used 768-bit RSA and a handful published SPF data in their DKIM record. None of these were highly-targeted organisations. The 512-bit keys were used to send (opt-in) bulk emails; most 768-bit keys were used to send one-to-one emails. Two out of the three selectors that used 512-bit keys included a year (2011 and 2012) which is good news (as they haven't created weak keys recently) and bad news (as they've been using weak keys for a very long period of time). I don't think this is just about highly-targeted domains though, even if the risk there is larger. An adversary could crack the DKIM key of LocalShop Ltd. to send a fake version of their weekly mailing with the latest offers. Make the links go to crypto-ransomware and you've earned back your investement of cracking the RSA key very quickly. (Note that this does make the assumption that signing emails with the DKIM key of a domain that has a reasonably good reputation significantly improves delivery rates. I am not sure how correct this assumption is, but I think DKIM was designed under the implicit assumption that this could become correct one day.) FTR, I do agree with others that in retrospect, including explicit key parameters in the RFC wasn't a good idea. I'm also fine to address this issue in a BCP if that is considered more appropriate - if only because the STD already says not to use keys smaller than 1024 bits - and I think it's a good idea to refer to NIST to determine what key parameters are considered secure rather than us making a somewhat informed decision. I don't think such a BCP should be so broad as to cover other protocols, including TCP, which is orders of magnitude more complicated. Martijn. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html