IMO, this suggestion would be better as an Informational and BCP note. I don't think it warrants a change to STD76.
We went through this already. We (DKIM WG) were well aware of the weakness of a smaller key but we had backward compatibility concerns so the proper verification migration path was set. I see this more as an implementation note. In our DKIM package, it was provided in the API as a functional "numbits" parameter with a default of 1024 but it is not settable via the sysop configuration/UI. IOW, 1024 is always used. No option for setting 512. What we can do in the future is add the option for higher sizes and even add the option to "[_] Invalidate 512 signatures". But IMV, that is Informational/BCP material. Not a change in the STD76 specification. -- HLS On 5/12/2015 6:35 PM, Murray S. Kucherawy wrote: > On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten > <martijn.groo...@virusbtn.com <mailto:martijn.groo...@virusbtn.com>> > wrote: > > > Why remove 512 support from the verification side? Does this mean the > > verifier will take valid 512 signature and make it invalid, no signature > > message? Is there a correlation out there that 512 bits signers are > more > > prune to be Bad Guys? Spammers? > > The problem here is that 512-bit keys can be trivially broken: it > takes less than 8 hours and about 100 USD to do so[1]. So there is > no way to be certain that the signer of the message is the same > organisation that published the (512-bit) DKIM key, even if that > organisation only were to send email that everyone would want to > receive. > > You are right to point out that the RFC says that "[t]he security > goals of this specification are modest", which indeed they are, > but I think 100 USD is well within the means of the kind of > adversary DKIM is trying to protect against. The story of Google's > 512-bit key that Scott already pointed to[2] gives at least some > anecdotal evidence about why this matters in practice. > > > Is it appropriate to change the protocol document for this? Isn't it > really more of a BCP? > > The size of the key doesn't affect interoperability, but rather the > receiver's choice to accept the signature as valid when it's based on > a weak key. > > I'm not arguing that it's a bad idea to discourage this practice, but > rather ruminating about whether this is the right way to do it. > > Then again, RFC6376 doesn't expressly say that keys smaller than 512 > have to be accepted either. Hmmm. > > -MSK > > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
