Subject: Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 23 Dec 2005 07:55:50 -0800 (PST)

On Fri, 23 Dec 2005, Stephen Farrell wrote:

> Hi Eric,
>
> Eric Rescorla wrote:
>>> The not-DKIM proponents want something better, for some value of
>>> "better".
>> 
>> More accurately, we want the charter not to foreclose the option
>> of doing something better, on the grounds that it's incompatible.
>
> I hope Tony's proposal to use the xmpp text instead resloves the
> charter issue for you.
>
> I think if we have a consensus on that text amongst both proponents
> and not-proponents then we can and should move on. (Which for this
> list means considering Jim's latest threats draft I guess.)

Stephen,

The issue with limitations due to text that says that authorization
keys will be placed and retrieved from dns is still open.

---
William Leibzon
Elan Networks
[email-masked]

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 23 Dec 2005 17:17:59 -0800

I have for some time become aware that the problem of deploying a protocol is considerably more challenging and difficult than the problem of developing a protocol.

That is the reason that only two protocols were submitted as input documents into this process rather then four. It is no longer a secret that VeriSign designed, developed and implemented a scheme essentially identical in all architectural respects to DKIM and demonstrated it under NDA terms several years ago. The reason that we did not go forward with the protocol proposal is that to do so would not help the creation of an environment where deployment could take place. Others made the same decision.

I agree with Keith, no industrial consortium should dictate the terms under which the IETF accepts a specification. Most of the criteria applied by the IETF are pretty clear, copyright and change control is passed to the IETF (or this strange trustee thing). I would like the IETF to be equally uncompromising about IPR and set out a limited number of choices for IPR terms. There is no shortage of standards forums, if a consortium wants to write a closed protocol that it keeps change control over or control through an discriminatory IPR regime then it can and should go elsewhere. It is a commercial choice, not a moral one. I have written proprietary code and open code, proprietary standards and open ones. I think that it would be better for the IETF and the constituencies it serves if it recognized that it is not a useful forum for developing closed standards but that is a different argument.

What does matter is deployment. I think that every group that comes to the IETF with a deployed, reasonably complete protocol has the right to expect that the standards process will respect the deployment imperative and avoid changes that are unnecessary or capricious. For example I still think it was a damn fool thing for folk in the URI group to try to require that all URIs be written in angle brackets, thus breaking millions of deployed clients with zero benefit. There are plenty of similar cases, unnecessary name changes to tags - if you think the referer tag is spelt wrong then wait for the next version of the OED, you will find that my way is now the right way.

Building on top of a legacy deployed base is often the best way to start deployment. I agree that some explanation is owed to explain why we are not using S/MIME here. The answer is simple, S/MIME is a technical success that meets 95% of the intended use cases. Our use case is not one of the original intended use cases and the design of S/MIME breaks our overriding design requirement that no legacy clients see a worse user interface. 

The fact that we need a new signature standard does not mean that we are rendering S/MIME and PGP obsolete. On the contrary I view DKIM as being a bootstrap for the S/MIME and PGP deployment process that stalled about five years ago. 

I do not see that the proposed charter wording changes to make it clear that change control is passed to the IETF and that the group works with the rest of the IETF need to be a show stopper.

People often worry more about what cannot possibly happen than what can. Let us imagine that the worst case scenario were to happen and the IETF was to agree to host the DKIM WG but then decide to insist that the entire specification be reworked as a version of S/MIME or use PKIX for key distribution or some other scheme that eliminates the advantages DKIM brings to the table and breaks the legacy base. All that happens is that the people who want to actually deploy something useful and meaningful walk out and a technical note appears shortly afterwards in another forum.

That scenario is a possibility in every IETF working group but it very rarely happens because most of us are here to get something to happen. It is only in rare cases such as when the WG chair is the noisy faction determined on their way at all costs and the AD is not inclinded to remove him because he is also an AD of another area and they have to work together that things start to fly apart, and even then there is a meta-level of accountability that can in theory be brought into play.

Equally passing change control does not and cannot prevent a fork in the specification - and even the new trustee scheme will not change that in practice.

Bad things can sometimes happen when you surrender control, but that is the whole purpose of the process. There are many people who are not going to implement anything until they know that it is open, unencumbered and fixed. Its the last point that is important, will the spec be tweaked endlessly or forked by numerous would be improvers as happened to RSS? 

-----Original Message-----
From: [email-masked] on behalf of Keith Moore
Sent: Fri 23/12/2005 1:53 AM
To: [email-masked]
Cc: John C Klensin; [email-masked]; [email-masked]; [email-masked]
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
 
> Apparently you expect the extensive, open group consensus process that 
> was pursued TWICE on this matter to have no import, but the last-minute, 
> vague whim of a few posters instead should hold sway.

Dave,

Unless you can cite an IETF BCP RFC that authorizes unchartered, 
self-appointed, ad hoc groups to dictate the terms of their charters, 
constrain the behavior of chartered IETF working groups, or overrule the 
decisions of IESG in chartering a group, please rest your case.

Keith

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 23 Dec 2005 17:43:57 -0800

Perhaps we could provide a material proof of what John is asking for if we published the other two schemes that are essentially identical to DKIM. I can certainly try to get the VeriSign spec released.

I think that if four independent high-level engineering teams come up with essentially the same idea at the same time then that is a pretty good reason to think that the approach is well founded and likely to be stable.

If people have a different view on how to solve the same problem let them start their own WG or submit an individual ID. 

What we have here is not just a coalition of companies it is a coalition of many of the best known security specialists who work on protocol design. If we ever have the Internet crimewave under control some of us might be considered experts.

This is not about 'pre-picking one solution' as some claim. It is about recognizing the fact that four independent groups that came up with the same idea have agreed to pool their essentially similar ideas and bring a joint proposal to the IETF supported by an even larger group.

I do not think it is reasonable for the answer to that proposition to be 'go spend 12 months defending your idea against everyone with an opinion and a keyboard'.

-----Original Message-----
From: [email-masked] on behalf of Michael Thomas
Sent: Thu 22/12/2005 8:18 PM
To: John C Klensin
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: WG Review: Domain Keys Identified Mail (dkim)
 
John C Klensin wrote:
> In addition, there is, I think, one other approach that might be
> appropriate, but only in very limited circumstances.  That
> approach applies where there is a well-thought-out approach with
> design team consensus, evidence of implementation, and no
> clearly-identified technical concerns.    Then, and only then, I
> think that an approach of "the WG gets to challenge the base
> spec and assumptions, but to change them only if there is good
> reason and consensus to do so" is plausible with a standards
> track target.  I think that XMPP, and the XMPP language,
> probably is an instance of that case.
> 
> Other than claims and counterclaims, I've seen little that would
> permit the IETF community to form a consensus about exactly what
> stage the DKIM work (and implementation, deployment, and
> demonstrate that it accomplishes whatever is being claimed) is
> really at, a consensus that seems to me to be necessary to
> determine whether it should be chartered as a WG if  there are
> going to be any restrictions at all on what that WG can
> consider.  That strikes me as sad since, beyond philosophical
> debates, it seems to me to be the key issue.

I obviously think it's closer to #4 than anything else. Note
I wasn't weighing in about whether this piece of word-smithy
vs that was better or not, just my concern that the lack of
negotiation/feedback make the backward compatibility problem
far more nettlesome than other protocols that have that
luxury. There is a substantial risk that a bunch of gratuitous
thrashing around -- or worse a greenfield makeover ala MEGACO --
will cause this effort to crater. Given MARID, I don't think
we get many chances and that this is really a situation where
the best is the enemy of the good.

As such, I think it's reasonable for the charter to limit the
scope of changes to those that will really tighten up the mature
parts of the specs instead of a, IMO, futile -- and destructive --
trip back to first principles. False dichotomy? Maybe, but not
out of the question if there is no limit at all, and that's
pretty bothersome for those of us who advocated taking this
to ietf and tried really hard to make this look like
something that would pass ietf muster.

Finally, I understand that for many people there are larger
principles at stake about the nature of ietf, etc, etc. I can't
tell you how thrilled I am that we are the posterboy for _that_
argument.

		Mike

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 30 Dec 2005 10:17:51 -0800

The objective here is to put the spammers out of business.

I trust that it is understood that this means a limit to the extent of the consensus.

Given the history of marid it was entirely reasonable to insist that the similar proposals were merged before the group was chartered.

 -----Original Message-----
From: 	Nathaniel Borenstein [mailto:[email-masked]]
Sent:	Fri Dec 23 14:32:17 2005
To:	william(at)elan.net
Cc:	Harald Tveit Alvestrand; [email-masked]; [email-masked]
Subject:	Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

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