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(_dot_)grooten(_at_)virusbtn(_dot_)com
<mailto: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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html