Michael Thomas wrote:
Arvel Hathcock wrote:
> I guess the main argument for the MUST on sha-256 would be to
> encourage moving away from sha-1 before there's much wider DKIM
> deployment.
A MUST would more than encourage, it would require :)
Isn't SHA-1 sufficient since it (a) isn't broken (b) is the least
computationally taxing (I assume) and (c) provides sufficient
protection for our use (we aren't protecting files full of credit card
numbers with DKIM).
Just a few data points:
1) sha-256 is about 55% the speed of sha-1 [*]
2) for smallish pieces of email, it's almost certainly the RSA overhead
that dominates.
3) I've heard tell that it's often the case the MTA's are IO bound. I
don't know how much this holds true these days on inbound MTA's
doing scanning/filtering.
Overall, my suspicion is that Moore's law will make this inconsequental
before there's even an RFC number for DKIM.
Yes. I don't believe there's an interesting performance issue here.
The point that DKIM signatures aren't meant to be high assurance is
also valid. However, sha-1 has been *seriously* weakened: 2^63 is a
lot less than 2^80, and such problems only ever get worse by
definition. So there is reason to think about whether it'd be ok
or not, were most instances of DKIM signatures to use sha-1.
And regardless of whether hash-collision based attacks are actually
a serious threat, (I reckon they're not really) if someone can
demonstrate colliding DKIM signatures, that does do damage to the
overall effort.
I'm not saying that the "MUST sha-256" argument is compelling, but
it does warrant consideration. (And the IESG will probably insist on
a good answer to the "why's sha-1 still allowed" question that they'll
inevitably ask.)
Regards,
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html