[ietf-dkim] comments on the threats draft

[Dave Crocker]

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/