On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten <
martijn(_dot_)grooten(_at_)virusbtn(_dot_)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