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

Reply via email to