Stephen Farrell wrote:
Hi Jim, All,
Does the following make sense?
In section 4.1 we include a couple of vulnerabilities where an
exploit would depend on the DNS being poisoned or otherwise
containing bad values (e.g. 4.1.12).
Since we're also proposing to use the DNS to store policy
assertions then there should be some analogous threat in 4.2,
perhaps one named something like "applying the wrong policy".
This makes sense to me. There is an analogous attack to 4.1.12 against
SSP, which I will add to section 4.2. I'm not sure this is quite what
was being described earlier in this message thread, but this one is clear.
One attack might be to delete everything to do with DKIM or
to put in a very open policy assertion so that unsigned
mail or 3-rd party signed mail would no longer look
suspicious.
I guess this could achieve a similar effect to replacing the
public key, but at less (run-time) cost to the attacker. I'd
further guess that replacing the public key would have higher
impact than this putative threat, but that the likelihoods
would be the same.
By the definition of "impact", I think it's about the same: it can
affect the verification of an entire domain. The attacker might also
wish to make valid mail from a domain look suspicious, and push out a
"NONE" policy. If it differs from 4.1.12 at all, it's in terms of the
capability that the attack gives you: it allows one to make mail look
more or less suspicious, but doesn't help them to create a valid signature.
I'm not saying that this is compelling, but I guess it makes
a certain amount of sense in the abstract.
If so, the question is whether its worth including in the
document?
I think so.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org