Folks,
I have only one real reservation. In section 6.3, discussing the message replay attack, esp. in 2nd paragraph... It is presented as if DKIM cannot be applied against replay since replay is indistinguishable from acceptable acts e.g. forwarding. This is not necessarily true. A legitimate application of DKIM may require senders to indicate specific recipient; this would allow replay prevention, of course in the price of requiring additional support to deal with legitimate forwarding.
"may require senders to..." requires a modification to the existing DKIM specification, albeit only constraining usage, rather than format. It's sounds like an interesting modification, as do many of the other ideas raised in these discussions. The question is whether it is *required* to have such changes added in the *first* round of IETF effort.
If folks feel it is required, then yes, discussion of the threat should be in the analysis document. If folks agree that it should be deferred for later work -- as do I -- then the threat analysis should NOT discuss it because the first round of effort will not be responding to that threat. My understanding of Replay threats is that they have some complexity and variety to them. Hence the restriction you suggest probably deals with some replay threats rather than all. Hence the extension is of limited benefit. Now, limited benefit can be very much better than none, but it seems to me that it reduces the need for dealing with the issue in the very first round of IETF work with DKIM. To make the larger implication: For an IETF effort like this to succeed, folks really do need to look for threats, requirements and functions that can be LEFT OUT, not for ones to include. It is the only way to bring the complexity down to a manageable size and reach the required consensus in any sort of timely timeframe. To the extent that folks find it possible to defer dealing with a threat, but they consider the threat really, really import to deal with "soon", then it might be worth having a catch-all section in the Appendix with all the comments folks think will be useful. d/ _______________________________________________ ietf-dkim mailing list http://dkim.org
