ietf-dkim
[Top] [All Lists]

Unequal treatment RE: Additional lookups (was Re: [ietf-dkim] Re: 1368 straw-poll)

2007-03-02 08:26:02

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

<Prev in Thread] Current Thread [Next in Thread>