Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
What I would have expected in a threat analysis of this type is that
one would start with a relatively broad view of the type of system
one was considering developing ("server-based message-based signatures
to prevent mail forgery") and then describe potential attacks on
such systems and the types of countermeasures that can be used to
protect against them.
Eric,
We seem to be suffering from trying to hit a moving target.
Hmm... Maybe, but I think my comments are in line with comments
I've made previously. It's possible that my comments don't
agree with Russ's, of course.
They don't. When the issue of what does or does not need to be in the threat
analysis came up back in August, I very specifically asked for guidance as to
what did or did not belong in there. I did so because I was confident that no
matter what we put in the document someone would come along with a differing
view and tell us we had it all wrong. I therefore wanted to get on the record
what was, and more important wasn't, needed.
Russ happened to be on vacation at the time and there were basically two sorts
of responses to my query: (1) That no clarification of this sort was really
necessary and (2) It was asserted that I was attempting to avoid doing a
proper analysis and such analyses are in fact needed.
The second response was nothing but a strawman, of course, and I don't
intend tp pursue it further here. As for the first response, well, now's
the time I get to say "I told you so".
In any case, Russ got back from his vacation and answered the questions I had
asked. Here is the list of questions the threat analysis needs to answer, taken
verbatim from his message of 17-Aug-2005:
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.
The task that Russ originally assigned was to describe the threats
that DKIM is designed to respond to. In other words, what problems
are there -- without DKIM -- that the addition of DKIM would fix?
That is, of course, quite different from describing attacks on DKIM,
which seems to be what you have just described.
No, I don't think that's what I'm describing. Indeed, my problem
with the current draft is largely that it's too narrowly focused
on DKIM.
What Russ asked for IS very narrowly focused on DKIM. You cannot have a
document with both a broad and narrow focus, so something has to give here.
What I'm interested in seeing is:
1. A description of the problem you're trying to solve.
As I noted here previously, I don't think it's sufficient to
just say that it's "forgery" while taking it out of the true
context, which is spam.
This is similar to what Russ asked for, but approaches it in a somewhat
different fashion.
2. A description of the generic architecture that you think will
help solve the problem and why.
I more or less asked about whether or not this sort of thing is needed in the
threat analysis. I said:
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.
Russ responded:
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.
So it seems he disagrees with you to some extent on this point.
3. Some indication of what the expected attacks on this kind of
architecture are.
I specifically asked about this one. I said:
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.
Russ responded:
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.
I also said:
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).
And Russ responded:
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.
Now, Mike has characterized this as a meta-argument between yourself and our AD
with us caught in the middle, and I'm afraid I have to agree with this
assessment. Your response to this characterization was:
A meta-argument? Are you saying that you think that Russ would like
you NOT to do the analysis I suggested? I'd be quite surprised to hear
that.
Then you need to be surprised, because I specifically asked about several of
the things you say need to be in there and was told, directly and clearly, that
including them was inappropriate (see above for specifics).
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org