ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] comments on the threats draft

2005-10-19 08:46:16
Stephen,

2. There should be a complete analysis, including threats caused by/to the DKIM
protocol. There is in fact some text along these lines (see the nits below),
but we should include as much as we can here.

I have been a strong supporter of doing the threat analysis and doing it before chartering. However I am now quite concerned that it is becoming an impediment rather than a benefit:

A few days before the last DKIM BOF, Russ told us that a requirements analysis would be required before chartering. A crash effort was put in place to create a draft prior to the BOF. The first version of the threat analysis primarily had threats TO dkim. That wasn't what Russ wanted -- he wanted threats that DKIM responds to. So that is what revision had. Recently, Russ said he wanted the document also to list HOW dkim responds to these threats. Now you are adding back the expectation that the document will also contain threats to dkim.

One of the very clear realities about requiring a threat analysis, before chartering the working group, was and is that there is no clear, precise, stable description of what must be in such a document. So we are now seeing exactly the problem that this permits: unstable requirements for it.

When the requirement was a simple, constrained "what threats does DKIM respond to', it made sense to have the document required before chartering. DKIM operates in a context that is fuzzy and that has an extremely problematic history. People bring a wide range of expectations for it. So the threat analysis document could/should serve to solidify community expectations (and needs) for the working group output. That would be enormously constructive for working group productivity.

What is emerging, however, is a problem that has plagued IETF work in the security area for at least a decade: A lack of stable, coherent requirements among the community knowledgeable security participants. Each participant tends to specify things that are quite reasonable, on their own. However each one has different requirements. And the requirements sometimes are not reasonable in the context of satisfying a particular community need. In addition, there is a tendency to have the requirements imposed late in a sequence. This utterly destroys productivity.

It would be helpful to find a way to resolve this problem quickly, so that DKIM can move forward on an aggressive schedule.

d/
_______________________________________________
ietf-dkim mailing list
http://dkim.org