> On Thursday 01 March 2007 21:00, Wietse Venema wrote: > > When a DKIM verifier gives unequal treatment to any of the > following: > > > > - no signature > > - broken signature > > - unsupported signature > > - other failure > > > > Then the bad guys will send their forged mail in the way > that receives > > the most favorable treatment.
Which is exactly what I have been saying all along. If you want to prevent this attack you have to take account of the fact that offering multiple key records provides an attacker with an opportunity to bamboozle you. What seems to be confusing people here is that they are trying to think about policy as if the issues were all identical to base. The problem results from the fact that the default actions you want to apply in policy are the opposite to those of base. So what is happening here is that people who have an 80:20 type of mindset keep going through the sets of cases and proposing various strategies that solve for specific cases. The problem is that a given verifier can only apply one strategy at a time. People are overlooking the fact that the strategies they are proposing are inconsistent. An unsupported signature in base is simply another case of 'unknown'. If you treat unsupported signature as 'unknown' in policy this means that you end up with rule "Whenever I see a message with a signature I do not understand I ignore the policy" We all agree that this is a bad thing since there are three outcomes here: VERIFIED : UNKNOWN and NONCOMPLIANT. In this case UNKNOWN is a more favorable outcome than NONCOMPLIANT. So allowing an attacker to force us into a situation where no signature or invalid signature leads to NONCOMPLIANT but a signature we cannot verify leads to UNKNOWN means that we have unequal treatment. We want to avoid unequal treatment of these cases if this is at all possible. But the alternative of treating an unverifiable signature as no signature results in the rule: "Whenever I see a message with a signature I do not understand I consider it to be inconsistent with policy if specified" This is utter nonsense that nobody is going to implement regardless of how we tag it in the specification. So what we are looking to do here is to expand the number of cases in which we can strictly enforce policy so that the mere presence of a signature that references a key record that permits an algorithm we do not support does not allow an attacker to nullify our signature policy. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
