[ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms
dotis at mail-abuse.org
Mon Jun 8 10:16:11 PDT 2009
On Jun 8, 2009, at 2:53 AM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: Douglas Otis [mailto:dotis at mail-abuse.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.
> 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 :
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
More information about the ietf-dkim