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". 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. 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? Stephen. _______________________________________________ ietf-dkim mailing list http://dkim.org
