Subject: Re: WG Review: Domain Keys Identified Mail (dkim) - msg#00089

Previous Message by Date: click to view message preview

RE: Re: WG Review: Domain Keys Identified Mail (dkim)

*** cutting all text from about 30 messages on the subject *** I'm on a plane now from Asia, finally catching up on the mailing list. After reading the postings, I've never been more concerned about the future of DKIM. Here's why: The list is quiet for weeks and then a storm of emails on the charter language. Are we really 30X more interested in charter language than in the technology? I think so! Disclaimer: my bias is toward moving DKIM forward on a reasonable, expedient path. But I'm smart enough to know that while my analysis may show a lack of critical flaws in the current specs, there may be some hiding somewhere. But after reading the last 30 email messages, I can't discrern any meaningful flaws that can be used to improve the technical specifications. So, I have to agree with Dave's oft-asked question: "what changes should be made to the technical specifications?" Right now I can't figure this out. Perhaps they are critical, maybe not. But right now I feel there is a tremendous amount of "concerns" and "don't do it *this* way" and a lack of "section X states blah. this is bad because of XYZ. change it to improved blah." this is the type of discussion I feel would benefit us tremendously, even if it leads to upsetting the apple cart. while i don't personally see the needs for radical changes to current DKIM specs, i'm open to them if someone can present clear data and recommended changes. if DNS is the wrong place for DKIM records or if Doug's weekly-proposed recognition scheme is the second coming of the IETF deity himself, great. somebody just present some hard issues and solutions! Let's hammer out the technical specifications, make them the best they can be and get this thing to market. Let's not discuss whether the charter should allow divergence from DNS, let's discuss the best solution and if DNS can be proven the wrong way to go, I'll gladly argue for this change. Let's be technologists, not philosophers. Two other comments: 1. In talking to a few hundred Japanese and Chinese IT folks last week, I tried to explain the promise and (many) limitations of DKIM and SIDF. Internet users are counting on us to add authentication of some type to SMTP. I would never support a fundamentally flawed or unworkable technology, but I fear that if DKIM standardization does not move forward with some positive actions in the next few months with tangible results in the next year, the technology deployers may lose interest and our wonderful specification may go unadopted, solving no problem. (I *do* support imperfect technologies all the time. I consider DKIM imperfect but not flawed or unworkable. But I look forward to specific examples of this together with solid solutions ready for inclusion in the specification.) 2. On adoption: I'm happy to hear of Arvel's success in propagating DKIM. Even the longest journey begins with a first step. I wish I could say the same for our customers. Unfortunately they are very actively deploying DK technology. They aren't interested in signing with DKIM if few are validating DKIM and they perceive too much in limbo concerning DKIM. They are looking forward to the consensus that gives them confidence in DKIM to switch from DK. Until then, they will stay with the legacy de facto standard. Brilliant or stupid, this is the market speaking, if I could get them to all do my bidding, I'd be a very rich man. :) pat

Next Message by Date: click to view message preview

Re: Re: WG Review: Domain Keys Identified Mail (dkim)

2. On adoption: I'm happy to hear of Arvel's success in propagating DKIM. Even the longest journey begins with a first step. I wish I could say the same for our customers. Unfortunately they are very actively deploying DK technology. Ours too. They aren't interested in signing with DKIM if few are validating DKIM and they perceive too much in limbo concerning DKIM. That's certainly true too. This can change once the first big ISP starts using DKIM. But that won't happen until the IETF process stabalizes and real work starts being turned out (this is just my view). -- Arvel

Previous Message by Thread: click to view message preview

Re: WG Review: Domain Keys Identified Mail (dkim)

Michael, Since I believe that, whatever else happens, it is better than those who are interested in DKIM get on with the work rather than spending more weeks or months splitting procedural hairs, let me see if I can explain the distinction I see. For context, I have a skeptical view of all spam-reduction techniques that are based on giving the recipient better ability to distinguish between good (or favored, or safer-than-most) messages from less-good or actually-bad messages by identification or classification of the point or origin (whether by person, by domain, by address range or routing, etc.). So I am not, in any way, opposed to DKIM because I favor some slightly-similar method; I'm almost equally skeptical about all of them, but believe that any plausible ideas are worth serious exploration. That said, I see three reasonable ways to pursue work in the IETF and a possible fourth: (1) One arrives with a more or less specific topic, and probably some ideas, gets an ordinary WG chartered, and then sorts things out and tries to end up with a standards-track document. This approach assumes that _all_ issues that fall within the problem definition in the charter are on the table, even though a sensible WG will prune options as quickly as possible. But any input that arises from pre-WG efforts is input, as if from a design team, and not binding on anyone, whether the design team (or other prior work) has consensus or not. (2) One arrives with what is, in essence, a finished product, ideally with claims of implementations, interoperability, and general soundness. Taking such a product to a WG is a waste of everyone's time. One takes it to the IESG, convinces them and the community that the work is appropriate for the IETF and as sound as you think it is, and get a four-week last call for standards track issued. (3) One arrives with an approach that needs exploration and exposure to the broader community. One gets a WG chartered to explore that particular approach, but with the target of producing experimental and informational RFCs that document the approach and its apparent strengths and weaknesses. Only after that process is completed and the agreed-upon specification (not some earlier version with some ideas about changes pre-standardization)implemented and tested in "live" situations is there a discussion about standardization. That discussion would presumably take the second path above unless there was still controversy about "best" solutions. In the latter case, if the IETF decided there was a reason to try to pick, we would probably need a WG to explore that, but its charter would be far different from a WG intended to do design, as in (1) above. 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. Now, for DKIM, there have been claims that it is widely deployed and successful but still needs IETF consideration. If that is the case, it would, by my typology, fall in the fourth category (but with an XMPP-like constraint, not the much stronger prior decision that seems to be implied by the current text. I think it has also been claimed that it is sufficiently finished and mature that IETF ratification and endorsement is needed, but no real changes are required or desirable. If that is the case, then the second option above would seem to be the right one. Others have claimed that there are known, and serious, technical deficiencies. If they are correct, then it seems to me that the only reasonable possibilities are the first or third options, i.e., either "no restrictions" or "not standards track at this point". 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. Just my opinion. john --On Thursday, 22 December, 2005 08:55 -0800 Michael Thomas <mat@xxxxxxxxx> wrote: > Cullen Jennings wrote: >> My current understanding is that the deployments >> are small enough that changes are still easy and that non >> backwards compatible changes are already expected. > >... > I'm not sure who Keith was talking about with his broad brush > assertion -- there are probably about 30+ people who've had > a hand in the creation of the current drafts before we ever > brought it to IETF, but my concern is that given complete > lattitude the resulting thrashing around will produce an > extremely narrow intersection between compatible senders > and receivers. Which will constitute failure in all likelihood. > > On the other hand, I think its really a stretch to say that > we are unwilling to listen, or that we're looking for a rubber > stamp. We have already agreed to -- and incorporated -- a > substantial backward incompatible change (the canonicalization) > due to feedback (and threats) we got. What I'm hoping for >... _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf

Next Message by Thread: click to view message preview

Re: WG Review: Domain Keys Identified Mail (dkim)

--On Thursday, 22 December, 2005 14:09 -0800 Dave Crocker <dhc2@xxxxxxxxxxxx> wrote: >> I >> think it has also been claimed that it is sufficiently >> finished and mature that IETF ratification and endorsement is >> needed, but no real changes are required or desirable. > > John, > > 1. That is not what has been claimed or sought for DKIM. > Ever. There is a world of difference between protecting > existing implementations and seeking "no real changes". Dave, I'm sorry, but some of the assertions that have been made about what "protecting existing implementations" means have been indistinguishable to me from "no real changes permitted". It would also be possible to interpret those same statements as "of course changes are permitted, but some largely undefined design group, or group of core participants, will decide what is acceptable and what unacceptably violates the existing implementations, without regard to WG participant or IETF consensus". My impression is that it is exactly that set of assertions, and the associated implication that some process outside the normal give and take of WG interactions will be used to determine which changes are acceptable and which ones are not, are exactly what has drawn those of us who have no DKIM-specific reservations into this discussion. If that interpretation was not what was intended, I would have expected Tony Hanson's suggestion about reuse of the XMPP language to be welcomed, not because of pressure from on high, but because it appeared to be an entirely sensible statement of what was intended, a statement that was less subject to misinterpretation than the one in the draft charter. But you took exception to that change in language. You apparently saw it as coming in response to an unreasonable, top-down, demand from a few IESG and IAB members. I saw it as a helpful and constructive suggestion, coming from a respected member of the community, to get things unstuck in a way for which we already had established precedent. You apparently see all of the objections and reservations that have arisen to the language of the proposed charter as coming from people who raised the issues during the earlier, BOF and other pre-charter, discussions, lost, and are now trying to raise them again. Without debating whether this is, in fact, an appropriate point to raise those issues even if they have been raised before (although I think that "final charter review" is exactly the right time to raise questions of WG scope and ground rules), I see people participating in this discussion, precisely because of the language about existing implementations, who have not previously been substantively involved with DKIM and who, instead, represent some small groundswell of community resistance to a WG that is thus constrained without any clear understanding of who gets to interpret the rules. > 2. This misrepresentation of things has been asserted > repeatedly and has been correctly repeatedly. >From my perspective, the "corrections" have been unpersuasive, for the reasons outlined above. They got particularly unpersuasive when resistance appeared to Tony's suggestion of more moderate language. > 3. At this stage, repeating this misrepresentation has taken > on the characteristic of willful distortion. And those who are on the other side of what I continue to believe is a series of misunderstandings about a reasonable and responsible desire to clarify the text and intent could equally well claim that a desire to stay with the current text no matter what, and to denounce anyone who wants to try to adjust it, is evidence that the particular text is, in fact, the result of nefarious intent. They, however, and to their credit, have made no such claim. john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf