David Hopwood wrote:
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?
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf