[ietf-dkim] DKIM Threat Analysis v0.06

[Dave Crocker]

> >    * 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