Re: what is a threat analysis?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Brian E Carpenter wrote:
> Michael, you've had some quite concrete responses which I hope
> have clarified things, but I really want to say that making
> Internet protocols secure isn't a hoop jumping exercise; it's
> more like a survival requirement, and has been for ten years
> at least.

Where did I say that?

Of course you didn't, and the implication that you did say that was nothing but
a strawman, a tactic I'm sad to say often seems to crop up in discussions on
the IETF list.

My issue is that if people are going
to invoke process, they should be prepared to define what
the process is.

Absolutely right.

And not just hand waving; concrete pointers
to documents that have been through the rough consensus
mechanism so that all parties can shoot for a common
goal.

I agree, although some degree of bootstrapping is permissible.

And to answer your question, no it hasn't been answered
because I've yet to hear from the people -- and there were
many on both the IESG and IAB -- who were asking for it.

And what we have heard has, for me at least, confused rather than clarified.

Do you seriously think you could write a "threat analysis"
given the definition in 2828?

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.

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.

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).

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.

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 Housely 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?

In any case, I for one am completely unwilling to spend time working on this
until I know what the goal is.

				Ned

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]