ietf-dkim
[Top] [All Lists]

[ietf-dkim] Policy decision tree outcomes

2006-11-13 14:13:27
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

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