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

[Douglas Otis]

On Jun 4, 2009, at 4:32 PM, Murray S. Kucherawy wrote:

>> Disagree.  This feature is about better informing recipients as to  
>> the
>> status of the signature.
>
> For the sake of enumerating implementations, the current libdkim  
> implementation does make a distinction between a signature that  
> failed to verify and one that couldn't be verified because the key's  
> approved hashes and the signature's methods don't line up and one  
> that simply failed DKIM verification.
>
> So if I am to apply my earlier arguments, I have to support your  
> point because it puts more information in the hands of the assessor.
>
> However, unlike x= and l=, I don't see any possible benefit in  
> making the distinction.

Whenever the DKIM key asserts the algorithm supported by the domain,  
attackers are prevented from spoofing "unverifiable" signatures from  
domains that have as of yet not made the transition.

>  For example, how can you tell an attacker that created a signing  
> algorithm of "rsa-whatever" from a site that accidentally posted a  
> public key with "h=watever"?

Consider the key's assertion represents a means to contain the level  
of potential confusion that a algorithm transition might make.   
Especially when being done within an exigent timeframe.

>  Are you sure you want to consider those as equivalent and apply the  
> maximum punishment rather than just treat the message as unsigned in  
> both cases?

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