On Jun 8, 2009, at 2:53 AM, Murray S. Kucherawy wrote:
-----Original Message-----
From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
It seems suitable to either reject or annotate a stern warning,
those messages where the domain refutes the algorithm claimed in
the DKIM signature.
Doug,
I'm still not convinced, but you have me thinking about it.
You're claiming that an attacker might craft a message claiming to
use a hash called something like MD6, and the absence of "h=md6" in
the corresponding key named by "d=" and "s=" in the signature should
cause a rejection or an appropriate annotation. But that would
presuppose the "a=" in the signature contains something like "rsa-
md6" and, further, that the verifier knows what that means.
Otherwise, wouldn't the verifier in that case just kick the
signature out claiming an unknown signing algorithm?
Given that there are currently only two possible values for "a=" in
a signature, the only actual attack vector here is an "rsa-sha1"
signature from a site that claims "h=sha256" or vice-versa.
Is that still something about which we should be concerned?
This feature provides a means to thwart exploits that will likely
leverage an introduction of a new algorithm. Email is replete with
examples of adoption taking years. As such, Jon is wrong about there
only being two states for a signature. As you have indicated,three
states are already supported :
1) Invalid
2) Valid
3) Algorithm Refuted
While initially, "Algorithm Refuted" may not play a major role, in the
coming years it might. No one can predict the future, so why not be
prepared? After all, the DKIM standard will need to retain the tags
for this feature. This feature assists with a difficult problem
created by the lack of negotiations for algorithm support between
sender and receiver. Since DKIM strives to be widely applied and
relied upon, providing a means to improve algorithm agility remains
prudent, nor is having this feature in place harmful.
This feature provides an enhanced agility only when senders start
asserting algorithms not initially listed by the standard. This
feature becomes especially useful when these new algorithms are not
always supported receivers, such as the example of MD6. Since all
compliant deployments of DKIM support both sha256 and sha1, this
feature does not offer an value at this time. In these cases, the
receiver should be able to determine whether the signature in
invalid. This feature will have value only when a new algorithm is
asserted by the sender that is not supported by the receiver.
In the case of a new algorithm, only the domains using the new
algorithm would be exposed to bad actors spoofing their new
algorithm. These domains should be able to take additional steps,
such the inclusion of as pass-phrases, to mitigate the potential
spoofing. Without this feature, other domains would be unable to
refute the use of the new algorithm, and so email handling would be
unable to refuse what should have otherwise been detected as an
obvious spoof.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html