Re: what is a threat analysis?

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

 





All the more reason for those in charge to be quite specific about what it is they're after, which still hasn't happened. All we get is more fixation on the words Mike happened to use in one message rather than responding to his issue with the lack of clarity in what's being asked for.


Minor comment about the "still":

It's a very short time after the IETF meeting. And it's August. Area Directors are allowed to take a vacation, and even have no Internet connectivity during the time.


Not-so-minor comment about guidance:

I am hard-pressed to believe anyone will argue against the utility of a guidance document. In fact that's why some of us suggested it to EKR during IETF week and it is why I made my IETF plenary comment. Since EKR has a track record of producing security-related document for non-security geeks, I'm hopeful we will get something useful.

But most of the IETF works has been done without benefit of such guidance documents. We have relied on the communication of guidance and criteria through other means. So I think the real question is whether reasonable, clear, stable criteria are being communicated? Since the "threat analysis" requirement is newly-imposed on the rest of us, one can expect a period of time where the communication is iterative and maybe even looks like a negotiation. The question, for this particular requirement, is whether there is a process to converge on clarity and stability for the requirement. Although it is early days, I am hopeful. (It helps that the construct involved has substantial history within the security community.)

So the question about the threat analysis requirement is whether an effort that has this requirement imposed on it gets the help it needs to satisfy it?

Noting that, in reality, an IETF effort always has quite a few requirements imposed on it, my own view is that most early-stage IETF efforts gets vastly less help than is needed. The truth of that matter is that we mostly rely on a self-forming group to figure things out on its own. At most, we assign a relatively experienced IETFer to help, but I'm not convinced that that helps as much as we would like.

For DKIM, our AD met with the design team at the beginning of IETF week and met with me at the end. He tried to give us pragmatic guidance at the beginning of the week. Some of seem to have understood it and some of us clearly did not. Also, EKR sent an extended note about threat analysis to the MASSS mailing list, prior to our BOF, rather than just showing up at the microphone and lobbing a bomb at us. I see two questions leading from the fact of our own confusion about the requirement:

          1. Is there something useful we can do on our own about this?

          2. Are we (going to get) assistance from our AD?

The answer to #1 *can be* yes. As is clear from a number of the threads on the DKIM list, the group is not all that cohesive or clear about the functional requirements DKIM is intended to satisfy. An analysis of the threats that DKIM is intended to respond to can significantly help resolve the confusion, separate from whether that analysis is exactly what we have been asked for. That is, getting the group to be clear and cohesive (rough consensus) about the goals, motivations, concerns, whatever of DKIM is an inherent good. And, indeed, there is some potentially useful discussion proceeding.

The answer to #2 is simply yes. Russ (and, by the way, Sam) are trying to be helpful. As someone with lots of practice complaining about pretty much everything, I could express all sorts of wishes about how things could be better. However the fact of the matter is that they are looking for ways to improve the likelihood of success and they are clearly willing to iterate with us to get there. It is difficult to reasonably ask for more.

That said, I hope we keep the pressure on, to get a document that specifies the threat analysis requirement in a way that is both clear and useful for working group productivity.

--

  d/

 Dave Crocker
 Brandenburg InternetWorking
 +1.408.246.8253
 dcrocker  a t ...
 WE'VE MOVED to:  www.bbiw.net

_______________________________________________

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]