[ietf-dkim] The key record upgrade attack

[Douglas Otis]

On Aug 4, 2006, at 7:48 AM, Michael Thomas wrote:

> Hallam-Baker, Phillip wrote:
>
>>> From: Stephen Farrell [mailto:stephen.farrell at cs.tcd.ie]
>>
>>
>>> My issue with this is that I don't see why this is much different
>>> from:
>>>
>>> Everyone supports rsa-sha256
>>>
>>> Alice publishes:
>>>
>>> 1. The policy statement 'I always sign'
>>> 2. A key record for algorithm rsa-sha256
>>>
>>> Mallet can produce a forgery of a message by Alice that is 100%  
>>> certain to be considered in compliance with policy - the  
>>> signature value just won't verify.
>>>
>>
>> The difference is that a signature that does not verify is treated  
>> as if it was not present and thus the message is not in compliance  
>> with policy.
>>
>> Verifiers must be able to treat the following conditions differently:
>>   "There is a signature here that I cannot verify"
>>   "There is a signature here that fails the verification process I  
>> support"
>>
>> What the attack does is to convert the policy Alice intends to  
>> express "I always provide a signature that you can validate" into  
>> "I always provide a signature but you may not be able to check  
>> it". That is a crucial difference.
>
> I probably haven't had enough coffee yet, but what would a receiver  
> do differently with that knowledge? In the end is looks like the  
> recever can't verify the signature regardless of the reason so it's  
> as good as missing from its standpoint.

During a transition, it would be important to communicate what will  
be offered and what has been deprecated.  Then these options MUST be  
available or the related signatures MUST be ignored.  While this  
policy could be found in the policy record, it should also be found  
in the deprecated key record.  Adding a tag to the key record does  
not break the key record, by the way.

-Doug