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
|