On October 12, 2005 at 23:23, Jim Fenton wrote: > I think there needs to be clear text somewhere on the scope of DKIM. > This will help determine the value DKIM offers and the security > threats to it. > > I'm guessing this should go in the introduction?
Yep. You may want to have a canned scope description that can be copied into each DKIM related document. > * 5.2.3 should mention the "window" of such, and similiar, attacks. > Is simple revocation (either via key or Doug's opaque ID method) > sufficient to minimize the damage and deter attackers? > > I expect the replay to happen effectively instantaneously, rendering the > revocation techniques that have been discussed ineffective. My thoughts also. That is why I'm interested in methods that can stop replay as it is attempted. Such methods may be separate technologies, but essential in dealing with the threat. > The list of attacks in section 6 is not intended to be exhaustive. But > canonicalization attacks should perhaps be in the Security Considerations > of the base draft. Okay. > * 6.3 should mention the use of complementary technologies, or > possible extensions to DKIM. To provide protection against replay > as it is happening, envelope-based technologies will need to be > employed. I'm not sure that systems that rely on reacting to the > attack after it has happened will be effective enough in deterring > attackers. > > By "envelope-based" I presume you mean SPF, Sender ID Framework, and/or > CSV. We should not create a normative dependency on any of these in the > DKIM specs, but I think they're worth mentioning in the threat analysis. Agreed. --ewh _______________________________________________ ietf-dkim mailing list http://dkim.org
