Subject: RE: what is a threat analysis?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 12 Aug 2005 07:02:37 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stephen Kent

> Dave & Michael,
> 
> In the DoD environment, a threat analysis for a system identifies the 
> classes of adversaries that the author believes are of concern, and 
> describes their capabilities and motivations. Russ's three questions 
> are a concise way of stating this:
> 	- The "bad actors" are adversaries.
> 	- Their capabilities allude to where the adversaries "fit 
> into the system" and what sorts of attacks they may employ of effect 
> their goals.
> 	- Their motivations indicate what they are trying to do, the 
> flip side of "what are we trying to prevent them from doing."

There is still a potential ambiguity here, there are actually two types
of threat analysis:

  1) Of the system in which the proposal is intended to provide a
control

  2) Of the proposal itself 

These are somewhat different, the first question is 'what problem is the
protocol intended to solve', the second is 'Does the protocol provide
the security assurances it is intended to'.

Both sets of analysis are important steps towards answering the question
'Will the protocol actually make a difference'.

One of the implicit criticisms of DKIM is that previous attempts to
apply cryptography to email only answered the second question, the first
was more or less taken for granted. Since a reasonably complete threat
model of the first type was provided before Russ asked the question at
the BOF I assume that he is (correctly in my view) asking for an
analysis of the first type.

Security is a property of systems, not protocols.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 16 Aug 2005 08:46:00 -0700

No, Jeff. Most threat analysis with which I am familiar are in regards
to a specific deployment or technology within explicit boundaries (i.e.,
a predefined context). Even so, I would never characterize my own work
as addressing "all possible threats" in that context, because new
exploits are continually being devised. 

One can identify classes of threats and establish controls to address
the more worrisome ones within the constraints of ones schedule, budget,
personnel, and available technology. Threat analysis provides management
with additional information to assist them to make hard choices
regarding feature definition and allocation of resources. 

However, in the IETF context, I imagine that its principal function
would be to identify security issues that protocol design may (or may
not) seek to mitigate. If it is known during design that the protocol is
inherently vulnerable to certain classes of exploits, then perhaps that
protocol could be designed with hooks to leverage another technology
that addresses those exploits.

--Eric

From: JFC (Jefsey) Morfin [mailto:[email-masked]] 
>>Therefore, I fear that either the security community will become even 
>>more
>>overworked or else a whole lot of not-very-helpful text will be
produced 
>>or else non-security people will become de facto security people. I'm 
>>hoping for the third result, but I fear the first two.

>Are your threat analysis covering all the possible threads on the 
>equipement as well as on the installations, processes, services, 
>communities, persons, cultures, etc. behind them?
>thank you

---

From: Russ Housley <[email-masked]>
Date: Wed, 17 Aug 2005 13:47:48 -0400

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