> > * Who are the bad actors? > > * Where do they fit into the protocol environment (eg, middle of net)? > > * What are we trying to prevent them from doing? .... > > In the hope of helping folks focus on the requirement at hand -- reaching > agreement on a threat analysis -- here is the text again, minus the > distracting first and last paragraphs.
Folks, Russ Housely is back from vacation and posted the following clarification on the IETF list <https://www1.ietf.org/mailman/listinfo/ietf>. I have edited out some initial text, to get to the focus on clarifying what he has requested as a threat analysis: Russ Housley wrote: > > For example, one sort would be to look at how DKIM can be directly > > attacked: Private key theft, replays, taking advantage of weaknesses in > > the delsp canonicalization algorithm and/or line count limits, hash > > function exploits, that sort of thing. This would be a highly technical > > analsysis of the DKIM proposal itself. > > I did not ask for this type of analysis. I think that it would be > inappropriate to ask for this kind of analysis prior to chartering a > working group. Obviously, the working group will make changes to DKIM, > and any change would impact such an analysis. > > > Another, somewhat overlapping, analysis would be of likely responses by > > spammers to widespread use of DKIM. This would include creation of bogus > > but similar domains, exploiting the gaps between the signature identity > > and message originator information, and so on. This is more a gaming > > exercise than anything else (and the obvious tool to use to describe the > > result would be an attack tree). > > I did not ask for this type of analysis. Although, it would be > interesting to speculate on the response of the bad actors if DKIM is > deployed. This analysis is not required in order for a working group to > be chartered. > > > And yet another would be to look at threats to email in general and > > attempt to figure out where DKIM fits in the overall email threat picture. > > This will have more the flavor of a justification for the DKIM approach > > and a specification of what DKIM is intended to do. > > Part of this is needed. We need to understand where the DKIM entities > reside in the email system. We also need to understand where the bad > actors reside in the email system. Of course, they may be in more than > one place. > > > My guess is that the third of these is what's being asked for. But that's > > just a guess on my part. And maybe I'm just being dense, but the list of > > questions to be answered provided by Russ Housley did NOT help clarify > > this at all: > > > > * Who are the bad actors? > > * Where do they fit into the protocol environment (eg, middle of net)? > > * What are we trying to prevent them from doing? > > Let me try to expand on these ideas. These are not the exact words that > I used when speaking to the BoF Chair, but they are close enough. > > 1. Who are the bad actors that DKIM is trying to thwart? Put another > way, if DKIM is deployed, what bad actors will have to find a different > way to perform their bad acts. Also, what resources do these bad actors > have at their disposal? > > 2. Where are these bad actors in the protocol environment? Where in > the email system do they pop up to perform the acts that DKIM is trying > to prevent. Again, different bad actors may appear at different places. > > 3. What are the bad acts that DKIM is trying to thwart? The first two > questions are really background for this question. > > Without answers to these questions, I do not believe that it is possible > to write a useful charter for a working group in this area. > > > In any case, I for one am completely unwilling to spend time working on this > > until I know what the goal is. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ ietf-dkim mailing list http://dkim.org
