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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 2 Mar 2007 07:23:48 -0800

> 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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 02 Mar 2007 22:01:18 +0100

Phillip,

To summarize some of this discussion, the chain of events is this:

 - The VERIFIED address perhaps along with the message is used as input 
to whatever reputation system there is.  The reputation service will 
return a value of ACCEPT or REJECT for each message.
 - UNVERIFIED leads to a query to SSP.  The results of the SSP query 
along with the message will be fed to the reputation service to produce 
a result of ACCEPT or REJECT.

It is out of scope for this working group to try and guess the special 
sauce in the reputation service, as I understand it.  The only question 
this leads to is whether the unverified address is valuable without a 
valid DKIM signature, and YMMV, especially in the beginning (like now).

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 Mar 2007 13:20:44 -0800

On Mar 2, 2007, at 1:01 PM, Eliot Lear wrote:

> The only question this leads to is whether the unverified address  
> is valuable without a valid DKIM signature, and YMMV, especially in  
> the beginning (like now).

Checking against a reputation or accreditation system before  
validating signatures prevents the acceptance level from leaking to  
bad actors.  This approach also eliminates wasted overhead related to  
signature validation.  The real question is whether DKIM will have  
any value (valid or invalid) without there being a disposition  
asserted by accreditation or reputation.  Only when the disposition  
for a valid signature is positive, would there then be value knowing  
the validity of the signature.

When negative-disposition -> reject;
When invalid -> ignore;
When valid -> annotate;

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 05 Mar 2007 16:36:49 -0000

> a result of ACCEPT or REJECT.

However, you want to be able to provide the reputation/whatever service  
with all the information which could be useful to it in reaching its  
conclusion, and that could well include a further breakdown to the nature  
of the UNVERIFIED.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html