Ah - bit of confusion there - I'm asking that the fuller analysis
be done for Feb, not before starting work.
S.
Dave Crocker wrote:
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