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