I generally try to stay out of discussions when everything has already
been said a thousand times, but this one is too important to ignore,
and I fear that people are arguing over red herrings rather than
speaking plainly about the underlying issue. So in what follows I will
try to give a reasonably simple explanation of why a bunch of long-term
IETF guys decided to form a private group to develop DKIM:
On Dec 21, 2005, at 12:23 PM, william(at)elan.net wrote:
Yes, the DKIM group clearly purposely bypassed discussions as part of
MASS (i.e. ietf open forum) in order to do it in private and leave
only one authorization method
This is completely backwards, the precise opposite of why a few of us
decided to start a closed, private group to define what became DKIM.
Far from trying to "leave only one authorization method," the DKIM
effort is an attempt to show, by example, how an arbitrary number of
such methods might eventually be elaborated and standardized. It is an
attempt to define one method first, as a step towards defining as many
of them as possible/necessary rather than arguing endlessly over which
is best. For most of us, support for DKIM does NOT imply opposition to
any other proposals related to controlling spam and related ills. A
lot of us who have worked on DKIM were previously active in trying to
bridge the gap between SPF and Sender-ID, and despite the
disappointments we'd still like to see that effort succeed, as well as
quite a few other anti-malware ideas and technologies.
To explain our reasoning, I must first posit a "reasonableness rule"
for spam/malware control (and, in what follows, I will use the term
"spam" broadly to include phishing, spim, viruses, and other
communication malware):
There are no silver bullets to "solve" spam, and our best hope is to
standardize and implement as many of the technically-feasible proposed
anti-spam mechanisms as possible, maximizing their ability to
cooperate while minimizing any technical and political barriers
between them.
Most folks who have taken a long, serious look at these problems seem
to agree with the substance of the above paragraph. The only people I
know of who disagree are the ones who believe they have a handle on
"the" solution. Those people tend, by definition, to be disruptive in
discussions about any solution other than the one they advocate. The
decision to "go private" to develop what we now call DKIM was made,
quite consciously, to keep those people (and too large a crowd) *out*
of the early stages of the detailed design.
I, for one, don't take lightly the notion of shutting anyone out of any
part of the standards process. But the history of IETF spam-related
efforts has so far been one of total, absolute, abject failure, and it
is worth trying to understand why. I believe that the problem is first
of all one of simple numbers: Any discussion of spam control attracts
so many interested parties as to swamp the normal IETF processes.
Worse still, however, the spam topic also attracts (IMHO) more than the
usual percentage of fringe voices. (Please note that by fringe voices,
I mean people whose technical insight might have outpaced their ability
to forge consensus. Fringe voices can be right or wrong, sane or
crazy, just not currently in the mainstream.)
Anyway, presuming the above "reasonableness rule," what we need is for
advocates of each "family" of spam control approaches to generate
detailed, consensus-oriented specs about a standardized way to
implement one particular approach to spam control., and to be maximally
compatible with the other methods. Unfortunately, this is such a
reasonable and boring idea that when one presents it to any
large-enough antispam forum, most people quickly agree, but the rest go
on fighting about which approach is best. Such arguments seem to be
much more exciting, for many, than the very hard work of trying to make
"all of the above" work.
Frankly, watching this happen multiple times has made many of us wonder
if the IETF could ever rouse itself to a serious attack on spam and
related problems. We started the DKIM design process in private, to
test the only promising idea I'm aware of: beginning in a forum that
is closed, but full of widely respected open standards veterans, to
produce a highly-polished first draft of a proposed standard for ONE of
the many spam control mechanisms being advocated in the wider, less
focused forums. The goal, from day one, was not to close *anyone* out
of the process, but to nurture a protected, focused environment in
which to more fully elaborate a single, specific technical proposal
before subjecting it to the wild open winds of the IETF. (To push the
metaphor further: the IETF climate for spam discussions has become
harsh enough to require nurturing seedlings in a greenhouse until
they're hardy enough to survive.)
Although I know that the arguments about the charter are being made in
good faith, after working on this for two years it's hard not to see
them as a great big red herring. I can't help but think that the real
argument isn't about the degree to which we want to favor compatibility
with the existing spec. Whatever the charter says, I promise you that
if someone comes up with a better way to do domain-level email signing,
it will get a fair hearing. The real issue is whether we'll permit the
reopening of the larger "which anti-malware technique is best"
questions that are guaranteed to torpedo the effort. More
fundamentally, the question is whether or not the IETF will EVER be
able to facilitate progress on multiple independent fronts in the
battle against spam, phishing, and the like, or whether we simply
prefer to argue about which technique is the best. Frankly, we chose
domain-level authentication as our first project because it looked like
one of the *least* controversial targets. (I won't even dare say in
public, at this point, what I think the next projects should be.) If
we can't create a WG that is acknowledged, by charter, to focus on this
one very specific *type* of malware control technology, I personally
will be about ready to give up on the IETF for any problem this hard.
(I have so far been a strong advocate for doing this work in the IETF.)
On the other hand, if all the people who think that DKIM advocates are
barking up the wrong tree would simply start their OWN (public or
private) design groups, to flesh out and standardize their own
approaches, we'd all be a lot better off, and most of us would support
most of those efforts. I personally think we need at least two dozen
new standards for email malware control, of which DKIM might, if we're
lucky, prove to be the very first. (What we should *really* be
discussing is setting up a new IETF "Malware Area" to house these
efforts, which sit uneasily in the Procrustean beds of the Security or
Applications areas.)
Let's be honest: We're not really arguing about the degree to which
the WG is biased towards the specifics of the DKIM draft, but rather
whether or not it is "biased towards" (I would rather say focused on)
this one fundamental approach to the exclusion of all others. The real
issue is whether or not the WG will permit the reintroduction of
discussions about whether the whole domain-based approach is the
"right" way to go for spam control. The fact is, it's not. There is
no right way, no silver bullet. If there's another approach that you
favor, let's flesh it out as well, eventually in its own WG. But we
won't get anywhere useful by consigning DKIM to death by a thousand
bureaucratic cuts.
Domain-level email signatures are a pretty good idea, one of many that,
taken all together, just *might* help us preserve the utility of email
and other open electronic communications. The purpose of the new WG
should be to produce the best possible domain-level email signature
standard, using DKIM as a concrete but reasonably flexible starting
point. Nobody is going to argue against considering really meaningful
improvements to DKIM, even if they introduce incompatibilities, but
neither will anyone benefit from reopening the question of whether
domain-level email signatures are worth doing at all. We need to
charter a WG to produce as good a version of this one idea as possible,
and move on to the next idea. If we can do that, and can then repeat
the process another twenty or so times, we *may* begin to see some real
progress on spam, phishing, and the like. Isn't that going to be hard
enough without this kind of squabbling over each little step? --
Nathaniel
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf