Bruce Lilly wrote:
Date: 2005-08-10 15:41
From: Michael Thomas <thomasm(_at_)cisco(_dot_)com>
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.
$ 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.
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).
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
<david(_dot_)nospam(_dot_)hopwood(_at_)blueyonder(_dot_)co(_dot_)uk>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf