[ietf-dkim] How MALLET PERFORMS a DOWNGRADE ATTACK

[Douglas Otis]

On Aug 2, 2006, at 3:12 PM, Hallam-Baker, Phillip wrote:

>
> NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK.
>
> As far as Bob is concerned the email is in compliance with policy  
> so he has to accept the message as being compliant with the  
> signature policy even though it is not.


On this I tend to agree with you.  However, until someone  
demonstrates a chronic non-catastrophic scenario, it would appear few  
want to go through the exercise.  From an overhead standpoint, the  
announcement that prevents the downgrade attack of a deprecated  
version, algorithm, or query method could be included within the key  
supporting the element declared as deprecated.  Once both the sender  
and verifier have upgraded, this would immediately thwart a downgrade  
attack.  When the verifier has not upgraded, it would act a warning.   
Both policy and key are found in DNS, so this limits the value having  
this announcement in policy, rather than in the key that must be  
acquired.  Depending upon how policy is used, it may not be acquired  
for every message.  However the sender can control whether the key is  
acquired.  Although the list of possible weak points is not complete,  
version could act as a catch-all.

>
> The selector mechanism is a simple fix.

I tend to agree with John, the selector mechanism seems overly  
complex.  Perhaps a convention of right-hand labels within the  
selector, or adoption of the r= mechanism could simplify this  
somewhat.  The r= mechanism also has the advantage of not impacting  
key management, which should also simplify when and where it gets  
applied.

-Doug