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
