Ned:
> And what we have heard has, for me at least, confused rather than clarified.
I have been away for the last week, so I hope I can resolve this thread
without causing any further confusion, anger, or frustration.
>> Do you seriously think you could write a "threat analysis"
>> given the definition in 2828?
RFC 2828 says:
$ threat analysis
(I) An analysis of the probability of occurrences and consequences
of damaging actions to a system.
Perhaps a different term is more appropriate. However, this was the term
that was used at the first MASS BoF.
> I certainly could write something that conformed to that (very vague)
> definition. Whether or not it would actually be useful, and whether or not
> it would be what's being asked for here, are different matters entirely.
The request for a threat analysis was made at the first MASS BoF. Several
people asked what problem was trying to be solved. The discussion that
followed made it clear to me that people were unclear how the signing of
email messages by the domain was going to help the Internet.
In Paris, on the Saturday before IETF 63, when I met with the BoF Chair,
and it was clear to me that there was a presentation prepared to answer
this question. I felt that this open item from the previous BoF deserved a
response. I believe that I was correct, as it was raised at the BoF from
the audience by Eric Rescorla, who was one of the people that spoke about
it at the first BoF.
> I actually think that, having read several threat analyses and even
contributed
> to a couple more, I know what a threat analysis is. The problem as I see
it is
> that there are several different sorts of threat analsysis that coupld
be done
> in the MASS/DKIM space, and it isn't clear what one we're being asked to
> provide.
>
> 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.
I hope this message provides the information that you are seeking.
Russ
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf