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