[ietf-dkim] Policy decision tree outcomes
pbaker at verisign.com
Mon Nov 13 13:06:58 PST 2006
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
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
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.
More information about the ietf-dkim