* 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