From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Charles
Lindsey
Sent: Tuesday, November 14, 2006 7:58 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Policy decision tree outcomes
On Mon, 13 Nov 2006 21:06:58 -0000, Hallam-Baker, Phillip
<pbaker(_at_)verisign(_dot_)com> wrote:
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.
AXIOM-2 denied.
If it finds a satisfactory authentication from a signer with
an apalling reputation, it should be _very_ suspicious.
I disagree, there is no reason to doubt the authenticity of the message in this
case. The message is authentic, the issue is authorization.
If the sender has an appauling reputation there is very little chance that its
fake since its almost certain to go in the bit bucket anyway.
In fact if the sender has a bad reputation I will not even bother to verify the
signature let alone the policy. I will return to this when proposing a
processing algorithm for my policy mechanism.
I don't see how reading a DKIM policy would modify the outcome here. If the
message has a signature that uses a trusted signature algorithm it is going to
be compliant with the policy 'I sign everything'.
Even if the group accepted my proposal to allow selector contraints and a
disparity was discovered we still have substantive proof that the message is
authentic. It might possibly be worth logging as an anomaly but the only
possible causes are administrator error (most likely) or the algorithm has been
compromised (hopefully very unlikely).
I am not clear what you mean by "acceptable/unacceptable signature".
A signature created with a trusted signature algorithm. So RSA2048 is
acceptable RSA128 is an unacceptable signature.
LEMMA-2: There is no value in distinguishing between any of
the cases
A, B, C, D
AXIOM-4: There is no value in distinguishing between
states that
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.
OK: correction no point in distinguishing between states that are reachable
with equal degree of difficulty.
AXIOM-5: Stastes A2, B2, C2, D2 can be reached by an
attacker [by
definition]
THEREFORE: LEMMA-2 follows.
FALSE
Lets look at the states again and how the attacker reaches them. I think that
you are focusing on interception while I was thinking only about forged
messages that were generated by the attacker without any reference.
A2: Message has no signature
Attacker simply generates a fake email without a signature header in
the normal fashion
B2: A signature is present with a signature type that the verifier cannot verify
Attacker receives an email from the party it is intending to
impersonate, reads the key record, determines that a rarely supported algorithm
is listed, generates spoofed mail for that key record.
C2: An acceptable signature is present that failed verification
Just generate some random Base64
D2: An unacceptable signature is present that passed verification
Break the algorithm
So I would breakdown as follows:
A2: Trivial
B2: Easy if the sender being impersonated sends lots of mail otherwise security
through obscurity
C2: Trivial
D2: Exceptionally hard even for 'broken algorithms'
The point about case D2 is that it only occurs if you have already decided that
the algorithm is unacceptably insecure and thus that it is not worth
distinguishing the signature from a forged one.
We might argue that there is value to making a distinction there but I am not
seeing it.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html