On Tuesday, May 12, 2015 03:35:37 PM Murray S. Kucherawy wrote:
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?
I think when key size got put in the protocol, then it's a protocol update to
change it.
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.
To me that's equivalent to saying choice of crypto algorithm doesn't affect
interoperability since it only affects the receivers choice to accept the
signature as valid.
I think that of course it's an interoperability issue. There has to be a
meeting of the minds on key signing and key verification in order for DKIM to
be interoperable.
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.
You have to set a floor below which it's not reasonable to accept signatures as
valid. Since receivers have no way to vet sender's key rotation policies,
taking an out like RFC 6376 and its predecessors do and say that keys smaller
that 1024 bits are OK for keys that aren't long lived is not tenable. That
and since DKIM was first deployed, at least for 512 bit keys, the not long
lived required to meet even the modest security goals of DKIM are
substantially shorter than the amount of time typically needed to ensure that
mail deliveries are completed (some fraction of a day at longest).
Key lengths less than 1024 need to be killed dead.
BTW (for reference), I'm prompted to do the work to make this change by a
recent change in opendkim [1] that removed the ability to mark messages with
small keys as DKIM fail.
Scott K
[1]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html