[ietf-dkim] When will we know the Threat Analysis document is complete

[Dave Crocker]

Stephen

> This is always tricky and the short answer is that we won't know since
> there may always be a vulnerability that we didn't think about.

Frankly, given the long history of Bad Actor creativity, I assume that the there 
is no issue of "may" but the certitude of "will".

Nonetheless, the threats document must satisfy a "sufficient" set of concerns.

The question is what those are and how will we know when we have satisfied them.

(Just to hammer home my point, I'll give offer an alternate, short, and somewhat 
flip response that is nonetheless meant seriously:  I was not asking about the 
technical competence of the document; I was asking about the process 
requirements for completing a milestone...)


> However, the IESG did accept our milestones and if we can demonstrate
> that we made a good faith and technically competent effort to do the
> job, then I think we have as good a defense as you can get in this
> case. That's a reason why getting comments on the threats draft is
> important. Silence on this produces no evidence (nor btw would simple
> acclaim).

The question is whether we are getting comments from the necessary folk?

The Security Area has a long history of being quite good at finding (legitimate) 
flaws.  So the rest of us might well engage in super-human diligence and still 
not satisfy the folks with an effective veto.

How can we be proactive, in this regard?


> So, for me, being able to show (via the I-D, issues list and mail
> archive) that we've done a good job should be enough. We'll see though.

Well, we already have some history with this document.

It began as a personal requirement to convince an AD to sponsor the working 
group.  That requirement was satisfied.

Since then, my sense is that the Security Area feedback we have gotten has been 
far, far less sanguine with our work.

Good project management requires responding to such a situation with more than 
hope. It requires a proactive effort to ensure meeting the deadline.



> PS: And in any case, IESG members are smart enough to be able to raise
> issues regardless, if that's what they want to do.

Stephen, the problem is that they raise them after our work is done.

Hence we enter the oft-cited cycle of potentially endless guessing and revision, 
notably protracting things far beyond the scheduled milestone.

I am seeking to understand how we can avoid this very common scenario, 
particularly for a deliverable is of a type that frankly *invites* the problem.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>