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