[ietf-dkim] Policy decision tree outcomes

[Hallam-Baker, Phillip]

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.