Subject: [ietf-dkim] Policy decision tree outcomes

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 13 Nov 2006 13:06:58 -0800

Before looking at the issue of whether downgrade attacks are important let us look at the possible outcomes of a policy mechanism.
 
LEMMA-1: The objective of policy is to allow a verifier to draw conclusions from the absence of satisfactory authentication
 
PROOF:
    AXIOM-1:   The objective of policy is to influence the verifier
    AXIOM-2:   A verifier only looks at the policy record if 
		      it fails to find satisfactory authentication.
    THEREFORE: LEMMA-1 follows from the axioms.

There is no point in having a policy unless the verifier executes different code paths as a result. The question then is the number of code paths.

A verifier will only look at a policy record in the following cases:

A:  No signature is present
A1:   Because there never was a signature
A2:   Because the message is fake
A3:   Because the message was modified after it was sent

B: A signature is present with a signature type that the verifier cannot verify
B1:   A genuine signature
B2:   A fake signature

C: An acceptable signature is present that failed verification
C1:   A genuine signature that failed because the message was modified
C2:   A fake signature

D: An unacceptable signature is present that assed verification
D1:   A genuine signature
D2:   A fake signature added by a party that has compromised the algorithm

LEMMA-2: There is no value in distinguishing between any of the cases A, B, C, D

PROOF
    AXIOM-3A:   It is not possible for the verifier to distinguish between
		case A1, A2 and A3
    THEREFORE: States A1, A2, A3 MUST result in the same outcome
    [Similar proof that B1=B2, C1-c2, D1=D2 omitted]

    AXIOM-4:    There is no value in distinguishing between states that
		can be reached by an attacker.

    AXIOM-5: Stastes A2, B2, C2, D2 can be reached by an attacker [by definition]

    THEREFORE: LEMMA-2 follows.

In other words all types of failed signature have to be treated IDENTICALLY. That is a verifier that is policy aware cannot consider the reason that a message is not compliant with policy. All forms of policy violation are equivalent.

It follows then that there are three possible outcomes for DKIM BASE + POLICY

1) An acceptable signature is found
2) The message is compliant with policy
3) The message is not compliant with policy

Case 2 includes the following sub cases

NO: NO POLICY is specified, anything A, B, C, D is compliant
PC-B: POLICY is specified, Commpliant signature cannot be verified
PC-D: POLICY is specified, Compliant signature is not acceptable

Case 3 includes the following sub cases

PF-C: POLICY is specified, no compliant signature can be verified
PF-B: POLICY is specified, non-commpliant signature cannot be verified
PF-D: POLICY is specified, non-Compliant signature is not acceptable

My concern is that unless the policy language is sufficiently expressive an attacker can force the system into outcome 2 with a fake message.

I will return to this in the next post with examples.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 14 Nov 2006 12:58:28 -0000

On Mon, 13 Nov 2006 21:06:58 -0000, Hallam-Baker, Phillip  
<[email-masked]> wrote:

> LEMMA-1: The objective of policy is to allow a verifier to draw  
> conclusions from the absence of satisfactory authentication
> PROOF:

AXIOM-2 denied.

If it finds a satisfactory authentication from a signer with an apalling  
reputation, it should be _very_ suspicious.

>     THEREFORE: LEMMA-1 follows from the axioms.

FALSE

......

> D2:   A fake signature added by a party that has compromised the  

I am not clear what you mean by "acceptable/unacceptable signature".

> 		can be reached by an attacker.

AXION-4 Denied.

Attackers can easily do bad things before the message is submitted to the  
MSA.

It is much harder to attack a message once it has left its originating  
MUA. You either need to have accomplices inside the ISP, or to be able to  
hack into it, or to have discovered a weakness in its procedures, ... .  
This limits the states that attackers can easily be reach, and verifiers  
are quite entitled to attribute more suspicion to the easier states.
>     THEREFORE: LEMMA-2 follows.
FALSE

-- 
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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Nov 2006 02:10:05 +0000

Hi Phill,

Thanks for taking the time to respond like this. I th

> In other words all types of failed signature have to be treated IDENTICALLY. That is a verifier that is policy aware cannot consider the reason that a message is not compliant with policy. All form…

You didn't actually show that or make that argument. You did make an
argument that A1,A2 and A3 aren't distinguishable. Same for the B's, C's
and D's but you never said that A2 is distinct from C1, and they are
distinguishable at the verifier. So your LEMMA-2 falls IMO, and
apparently all that follows,

S.