[ietf-dkim] RFC4871bis - whether to drop -- h: Acceptable hash algorithms

[Douglas Otis]

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.
>
> 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