Subject: Re: what is a threat analysis?

From: Bruce Lilly <[email-masked]>
Date: Wed, 10 Aug 2005 17:30:32 -0400

>  Date: 2005-08-10 15:41
>  From: Michael Thomas <[email-masked]>

> Having a "threat analysis" was brought up at the plenary by Steve
> Bellovin as being a Good Thing(tm).
[...]
> So, if this is going to be yet another hoop that the IESG and IAB
> sends working groups through like problem statements, requirements
> documents and the like, I think it ought to be incumbent on
> those people demanding such things to actually both agree and
> document what it is that they are demanding.

See FYI 36 (a.k.a. RFC 2828) for the definition of threat analysis.

RFC 3552, "Guidelines for Writing RFC Text on Security Considerations",
may also be helpful (although it does not use the exact term "threat
analysis").  All RFCs must contain a Security Considerations section
(RFC 2223, section 9).

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

---

From: David Hopwood <[email-masked]>
Date: Thu, 11 Aug 2005 00:58:23 +0100

> See FYI 36 (a.k.a. RFC 2828) for the definition of threat analysis.

    $ threat analysis
       (I) An analysis of the probability of occurrences and consequences
       of damaging actions to a system.

(That's the whole of the definition.)

This is not a property of a protocol (or of anything that the IETF
standardizes). It depends on how people will use the protocol, and how
attackers will respond to that use, which is *always* unknown at the
time when threat analyses are typically asked for. Indeed, if it were
possible to give an accurate assessment of "the probability of occurrences
and consequences of damaging actions to a system", it would probably be
only because the thing being proposed has a very narrow range of
applicability.

> analysis").  All RFCs must contain a Security Considerations section

That RFC indeed has some very sensible discussion of threat models (not
the same thing as a threat analysis by the RFC 2828 definition). What it
says is:

    The Internet environment has a fairly well understood threat model.
    In general, we assume that the end-systems engaging in a protocol
    exchange have not themselves been compromised.  Protecting against an
    attack when one of the end-systems has been compromised is
    extraordinarily difficult.  It is, however, possible to design
    protocols which minimize the extent of the damage done under these
    circumstances.

    By contrast, we assume that the attacker has nearly complete control
    of the communications channel over which the end-systems communicate.
    This means that the attacker can read any PDU (Protocol Data Unit) on
    the network and undetectably remove, change, or inject forged packets
    onto the wire.  This includes being able to generate packets that
    appear to be from a trusted machine.  Thus, even if the end-system
    with which you wish to communicate is itself secure, the Internet
    environment provides no assurance that packets which claim to be from
    that system in fact are.

and later it also mentions replay attacks, man-in-the-middle, etc.

IOW, the threat model is much the same for all Internet protocols. Of course,
it's possible that a particular protocol may raise additional issues (for
example, the possibility of conspiring users being able to break a security
protocol, or reliance on a trusted party that would be a single point of
failure). But I agree with the thrust of Michael Thomas' point: it often
isn't clear what people who ask for a threat analysis are really asking to
be stated that isn't already obvious.

 > At the MASS/DKIM BOF we are being required to produce such a thing as a
 > prerequisite to even getting chartered as a working group.

A more pertinent request at that stage might be, "Please clarify the security
requirements for this protocol." IOW, what is the protocol supposed to
enforce or protect, under the assumption that it will be used in the Internet
environment with the "fairly well understood threat model" described above?

-- 
David Hopwood <[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Aug 2005 12:13:42 +0300

> environment with the "fairly well understood threat model" described 

Hmm. It may be that its well understood what the threat model in the
Internet. (But if so, why are we having so many problems?)

I would claim that its well understood what the communications
security threat model is between two peers.  Unfortunately, this
is often too simplistic, and we need to worry about other issues
as well.

For instance, we typically have more than two parties.
In the e-mail example we have users, mail agents,
domains, and intermediate servers. What are the roles,
motives, and capabilities of these different players,
and how does that affect the threat model? And yes, e-mail
security is probably one place where you want to worry
about what happens when some of the players themselves are
compromised.

Typically, we also have interoperation with the
part of the world that does not yet have the new security
thingy that we are developing. This needs to be accounted
for. And what does the protocol do, and what bad things can
happen if it is attacked (service disruption, dossing innocent
3rd parties, exposing private information, etc.)? Sometimes
we end up in overkill solutions that are hard to deploy, so
you want to make sure the protections match the threat.

--Jari

---

From: Philip Guenther <[email-masked]>
Date: Thu, 11 Aug 2005 03:55:54 -0700

>> From: Michael Thomas <[email-masked]>
...
>requirements for this protocol."

I believe that the "threat analysis" that the proposal authors created
in the days before the BOF did the above, documenting how DKIM could be
attacked, what it depended on or assumed, etc.

IMHO however, that's quite different from what ended up being the
sticking point at the BOF, which you see as a paraphase of the above:

>IOW, what is the protocol supposed to

To me, _that_ question sounds more like "what does this accomplish?",
which belongs in a use cases doc, or maybe flipped around and placed in
a requirements doc.  In the case of DKIM, that can be phrased as "How
does this address items in the threat analysis for SMTP and the Internet
email architecture?"  From the people I've talked to and what happened
at the BOF, it seems that at least some of the requests that came across
as being for "a threat analysis" were intended for this latter meaning.

IMHO, the phrase "threat analysis for <X>" should refer to the analysis
of attacks, dependencies, and assumptions of <X> and _not_ include the
list of threats to other protocols that <X> addresses.  Those aren't
threats to <X>, they're *opportunities* *for* <X>!

But maybe the people who live and breath security analyses find that the
broader meaning is more useful.  If so, *someone* should document that
fact and security people should actively refer to that document when
requesting such analyses for the benefit of those of us who aren't
versed in the jargon.  That may be a good idea even if security people
prefer the narrower meaning, given the incredibly vague definition in
the FYI cited by Bruce Lilly.

Anyway, a miscommunication occured that resulted in time wasted.  Not
the time spent on the DKIM threat analysis, as that'll be needed later,
but rather the time of _many_ people spent at a BOF that was less
productive than it could have been.  The point now isn't to blame anyone
but rather to avoid this communication failure in the future.  How can
we do that?

Philip Guenther
"Just an email guy"

---

From: David Hopwood <[email-masked]>
Date: Thu, 11 Aug 2005 14:49:03 +0100

Jari Arkko wrote:
>> A more pertinent request at that stage might be, "Please clarify the 
>> security requirements for this protocol." IOW, what is the protocol
>> supposed to enforce or protect, under the assumption that it will be
>> used in the Internet environment with the "fairly well understood
>> threat model" described above?
> 

Several reasons (which are not independent):

  - most of the protocols that we *deploy* are not secure in that model.
    We need to pay more attention to aspects of protocols that act as
    obstacles to deployment, and in particular reduce the costs (monetary,
    support, reliability, usability, performance, etc.) of using more
    secure protocols.

  - although the assumption of intrusion-resistant end-systems is necessary
    for security, the operating systems running on most machines (particularly,
    but not exclusively, Microsoft Windows) do not adequately support it.
    It's like building on sand.

  - most security problems are treated as just implementation bugs to be
    patched. This does not address the fundamental design flaws that lead
    to these problems being so common and having such serious effects,
    including in particular:
      * use of unsafe programming languages (that is, languages in which
        common errors cause undefined behaviour)
      * the property of conventional operating systems that programs
        run by a user almost always act with the full authority of the user.

  - even where implementations of systems correctly support secure protocols,
    they are often configured to be insecure by default; insufficient attention
    is paid to reducing the effort needed to produce a secure configuration,
    to make this effort incremental as users start to make use of functions
    that require configuration, and to reduce potential sources of error.

  - user interfaces do not give the necessary information for users to make
    informed security decisions, or else give too much information and do
    not make it clear what is important. There is hardly any HCI testing of
    security interfaces.

  - there is an unhelpful perception that security and usability are necessarily
    in opposition, which leads to system designers being satisfied with designs
    that are not good enough from the point of view of being simultaneously
    secure and usable. The paper "User Interaction Design for Secure Systems"
    at <http://www.sims.berkeley.edu/~ping/sid/> is essential reading. Here's
    an important point from its introduction:

      Among the most spectacular of recent security problems are e-mail attach-
      ment viruses. Many of these are good real-life examples of security
      violations in the absence of software errors: at no point in their
      propagation does any application or system software behave differently
      than its programmers would expect. The e-mail client correctly displays
      the message and correctly decodes the attachment; the system correctly
      executes the virus program when the user opens the attachment. Rather,
      the problem exists because the functionally correct behaviour is
      inconsistent with what the user would want.