On 5/12/2015 11:31 AM, Martijn Grooten 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.
Hi Martijn,
Agree, but verifiers still need to support the 512 key signer, unless
the new update is mandate new logic of "invalidate all 512 bit
signers" or "Verifiers MUST NOT support 512" or in short, don't code
for it.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html