1) DKIM is a security technology. That means it is a tool for solving
some particular security problem. We need a clear definition of
the threat that DKIM and the MASS problem space are attempting to
address. That definition is needed for us to determine if DKIM
actually does what it claims to do at a security level. Russ and
I will not sponsor a working group unless this question is clearly
answered.
DKIM is designed to address certain types of spam and phishing threat by
allowing emails to be authenticated by means of cryptographic signatures
bound to keys distributed via the DNS.
DKIM is also capable of being used as a component within a comprehensive
program to address these threats by means of simple extensions to the
existing core. Combined with an accreditation mechanism DKIM allows
email servers to be held accountable (accountability = authentication +
accreditation + consequences) and for strong identity assertions to be
communicated in a form readily understood by the user (e.g. via PKIX
Logotype extension)
2) The BOF needs to show there is a consensus in favor of a MASS
solution based on DKIM. Showing that people are interested in
MASS cannot be used to justify this. You need to show there are
people who are interested in DKIM specifically.
There is a significant sub-group (15-20 members) that is in favor of a
solution that is backwards compatible with DKIM unless there are very
strong reasons to make a change.
Several members of this group, including VeriSign have chosen not to
submit competing proposals that they have developed because there is no
compelling difference between email signature proposals based on
authentication headers and DNS based key infrastructure.
3) You need to address concerns about how MASS might negatively impact
the mail architecture, business models of ISPs or otherwise is a
reason the IETF may not want to standardize DKIM. In other words
it is not enough to show that there is a consensus in favor of
DKIM, you also need to show there is no consensus against DKIM for
some particular reason.
DKIM is by design intended to negatively impact the business models of
spammers.
The impact on the network infrastructure is reasonable and certainly
lower than the impact of mechanisms such as S/MIME or base64 encoded
attachments.
The impact on the DNS needs to be closely understood but is certainly
not unreasonable.
4) You need to get enough agreement on a charter that you can achieve
achieve consensus on a charter during the WG creation process.
The main disagreement on the charter is whether the scope should be
defined so tightly that only the original DKIM draft can be considered
or whether it should allow for the interaction between DKIM and other
network infrastructure (in particular PKIX) to be understood.
My view is that considering a wider scope would assist understanding of
the specification and allow for quicker convergence.