Re: WG Review: Domain Keys Identified Mail (dkim)
I support the new charter and thank those who spent the time discussing it and walking through alternatives. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
agreed. Tony Hansen [EMAIL PROTECTED] John Levine wrote: Here is the revised proposed charter text: Thanks for pulling this together. If I had unlimited time to waste, I might niggle about a word or two, but it's fine as is, and I look forward to moving ahead and getting some work done. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Here is the revised proposed charter text: Thanks for pulling this together. If I had unlimited time to waste, I might niggle about a word or two, but it's fine as is, and I look forward to moving ahead and getting some work done. Complete ageement here. This is plenty good enough to move forward. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
I have been listening to this discussion. As the area advisor for this proposed working group, I have made a few changes to the paragraph that has caused so much debate. The revised text is largely based on the XMPP charter text posted by Tony Hansen. However, we know that some changes are absolutely necessary. Jim Fenton has given one example in the area of canonicalization. While I expect each and every non-backwards-compatible change to be discussed on the mail list, I do not think that an RFC needs to include the rationale. Thus, I have dropped the words that might be construed this way. Here is the revised proposed charter text: Domain Keys Identified Mail (dkim) == CHAIRS: TBD SECURITY AREA DIRECTORS: Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] SECURITY AREA ADVISOR: Russ Housley [EMAIL PROTECTED] MAILING LISTS: General Discussion: ietf-dkim@mipassoc.org To Subscribe: http://mipassoc.org/mailman/listinfo/ietf-dkim Archive: http://mipassoc.org/pipermail/ietf-dkim/ DESCRIPTION OF WORKING GROUP: The Internet mail protocols and infrastructure allow mail sent from one domain to purport to be from another. While there are sometimes legitimate reasons for doing this, it has become a source of general confusion, as well as a mechanism for fraud and for distribution of spam (when done illegitimately, it's called spoofing). The DKIM working group will produce standards-track specifications that allow a domain to take responsibility, using digital signatures, for having taken part in the transmission of an email message and to publish policy information about how it applies those signatures. Taken together, these will assist receiving domains in detecting (or ruling out) certain forms of spoofing as it pertains to the signing domain. The DKIM working group will produce a summary of the threats that are addressed by the proposed standards-track specifications, while acknowledging their limitations and scope. The DKIM working group will also produce security requirements to guide their efforts, and will analyze the impact on senders and receivers who are not using DKIM, particularly any cases in which mail may be inappropriately labeled as suspicious or spoofed. While the techniques specified by the DKIM working group will not prevent fraud or spam, they will provide a tool for defense against them by assisting receiving domains in detecting some spoofing of known domains. The standards-track specifications will not mandate any particular action by the receiving domain when a signature fails to validate. That said, with the understanding that guidance is necessary for implementors, the DKIM documents should discuss a reasonable set of possible actions and strategies, and analyze their likely effects on attacks and on normal email delivery. The DKIM working group will not attempt to establish requirements for trust relationships between domains nor to specify reputation or accreditation systems. The DKIM working group will consider mailing-list behaviour that is currently deemed acceptable, will make every effort to allow such mailing lists to continue to operate in a DKIM environment, and will provide a plan for smooth transition of mailing lists that fail to operate. The specifications will also advise mailing lists on how to take advantage of DKIM if they should choose to do so. The signatures will use public-key cryptography and will be based on domain name identifiers. Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. The specifications will be based on the following Internet Drafts: * draft-fenton-dkim-threats * draft-allman-dkim-base * draft-allman-dkim-ssp These documents represent experimentation and consensus from a number of designers and early implementors. Experimentation has resulted in Internet deployment of these specifications. Although not encouraged, non-backwards-compatible changes to these specifications will be acceptable if the DKIM working group determines that the changes are required to meet the group's technical objectives. The resulting protocols must meet typical criteria for success. In addition to security, these include usability, scalability, ease of deployment, and cryptographic algorithm independence. To prevent this task from becoming unwieldy, several related topics are considered out of scope for the DKIM working group. These topics include: * Reputation and accreditation systems. While we expect these to add value to what is defined by the DKIM working group, their development will be separate, and is out of scope for the DKIM working group. * Message content encryption. * Additional key management protocols or infrastructure. * Signatures that are intended to make long-term assertions beyond the expected transit time of a message from originator to recipient, which is normally only a matter of
Re: WG Review: Domain Keys Identified Mail (dkim)
Here is the revised proposed charter text: Thanks for pulling this together. If I had unlimited time to waste, I might niggle about a word or two, but it's fine as is, and I look forward to moving ahead and getting some work done. R's, John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Value of Reputation (was Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim))
Nathaniel Borenstein [EMAIL PROTECTED] wrote: On Dec 24, 2005, at 4:09 PM, Douglas Otis wrote: Reputation remains the only solution able to abate the bulk of abuse. ... I think most of us pretty much agree about the critical role of reputation. I've noticed a lot of what I call lip service about the critical role of reputation. To say this differently, many folks seem to think you can choose a reputation system almost at random, and it's sure to improve your signal/noise ratio, unless you've chosen the wrong one. (which, I suppose, is a tautology...) But, in my view, we have no basis to choose the right one unless we have a good understanding of what it measures and a workable idea of how to end run when it falsely rejects good messages. I see the cycle as going like this: We need at least one standardized, moderately-useful system for weakly authenticating the sources of messages. Once we have that, we have the minimal data that a reputation system will require to be able to start doing something at least mildly useful. A lot depends on what we mean by weakly authenticating. People who take security seriously always call the authentication inherent in an established TCP connection weak authentication; but in fact it represents a pretty-darn-good correlation. Thus blacklists based on IP address alone have an excellent correlation to sending SMTP clients which have, at some time, sent abusive email. (Their problems lie elsewhere.) OTOH we have schemes running which don't claim correlation much above 60%, and offer no assurance the correlation will remain that high. These, IMHO, don't qualify as useful authentication, but it's hard to argue they fail to be weak authentication. Once we have *that*, we will have (in our reputation systems) a built in market for additional systems for (perhaps less weakly) authenticating the desirability (not necessarily solely due to the source) of incoming messages. I don't agree with Nat here. As a practical matter, _many_ folks will prefer sorting through 100 spams to losing one good email. I see darn little market for anything which can't get it 99% right. What I think we're seeing is folks that design a system for their own use, achieve an accuracy of sorting sufficient for their needs, and offer it to others because they see their marginal cost (per new customer) as essentially zero. Further, until the customer abandons an existing method, the barrier to adopting an additional method is pretty close to 99% correct identification of email which passed the existing method(s). This is _not_ an encouraging situation for entrepreneurs. To some extent, there's a chicken-and-egg problem with authentication and reputation technologies. My hope for DKIM is that it will give us one good enough egg to produce a chicken, which can then (in much the manner that Cain and Abel found their wives, I guess) facilitate a whole new generation of authentication technology eggs. I find the challenge of designing a reputation system based in DKIM a bit overwhelming. DKIM offers assurance that a domain has taken part in the transmission of an email message containing certain headers (which the recipient probably never sees), but no assurance that anything else hasn't been changed since then. There's no assurance that the message isn't a replay attack, nor is there assurance that the original hasn't been lost. This is _not_ an attractive base upon which to build reputation. When reputation is applied against an authorization as an identifier, innocent email-address domain owners will be seriously harmed. Abusers will find acceptance methods for an authorization scheme. Doug is complaining about the difficulty of designing a useful reputation system on such a base. I entirely agree with him there. But I wish it to be clear I am not complaining about reputation services being out-of-scope in the DKIM charter. I prefer it that way: otherwise I'd be facing a serious challenge trying to cobble on a useful reputation heuristic, with really no hope of meeting the charter deadlines. I'm really not complaining at all: I'm just trying to bring some sense of reality to what we should expect of DKIM-based reputation systems. Yes, every one of these schemes will be flawed. That is why we need to understand A) the role of weak authentication (weeding out some but not all of the bad guys at any point in time, and using multiple sources of information to judge the desirability of a message) Expressed this vaguely, there's nothing to understand. We'd need useful estimates of what fraction of bad guys will be weeded out and what fraction of good guys are (wrongly) weeded out. I'm not sure any useful estimates of that can be found. and B) the need for a continually evolving set of (ever-stronger, we hope) mechanisms for proving that a message is desirable to the recipient. This
The Value of Reputation (was Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim))
On Dec 24, 2005, at 4:09 PM, Douglas Otis wrote: On Fri, 2005-12-23 at 17:27 -0500, Nathaniel Borenstein wrote: 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. There is danger viewing any abuse control mechanism as representing a authorization scheme. The control method should strive to identify the source of abuse, and not just whether the message has been authorized. The DKIM signature provides a fairly strong indication of the message source, with a normal potential for abusive replay as with any cryptographic method. I'm sorry, the authorization method was an echo of the term used in the mail I was replying to (which is why it was in quotes). I was really trying to generalize to a whole range of technologies without making my wording too awkward. Perhaps I should have replaced such methods with antimalware technologies or abuse control mechanisms. In any event, I fully agree that the term authorization, in this context, is both A) insufficiently generalized, and B) troublesome on countless philosophical grounds. Reputation remains the only solution able to abate the bulk of abuse. The word only makes me cringe a bit in any discussion like this (a global fascist state, for example, is another possible solution), but I think most of us pretty much agree about the critical role of reputation. I see the cycle as going like this: We need at least one standardized, moderately-useful system for weakly authenticating the sources of messages. Once we have that, we have the minimal data that a reputation system will require to be able to start doing something at least mildly useful. Once we have *that*, we will have (in our reputation systems) a built in market for additional systems for (perhaps less weakly) authenticating the desirability (not necessarily solely due to the source) of incoming messages. To some extent, there's a chicken-and-egg problem with authentication and reputation technologies. My hope for DKIM is that it will give us one good enough egg to produce a chicken, which can then (in much the manner that Cain and Abel found their wives, I guess) facilitate a whole new generation of authentication technology eggs. When reputation is applied against an authorization as an identifier, innocent email-address domain owners will be seriously harmed. Abusers will find acceptance methods for an authorization scheme. Yes, every one of these schemes will be flawed. That is why we need to understand A) the role of weak authentication (weeding out some but not all of the bad guys at any point in time, and using multiple sources of information to judge the desirability of a message) and B) the need for a continually evolving set of (ever-stronger, we hope) mechanisms for proving that a message is desirable to the recipient. Some of those mechanisms will also involve (ever-stronger, we hope) sender authentication, but others could eventually involve technologies as unrelated to authentication as anonymous payment. -- Nathaniel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
On Fri, 23 Dec 2005, Nathaniel Borenstein wrote: 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: I think simple explanation is the one you can fit in one sentence, this wasn't it... 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. Talk about red herring. I specifically meant authorization method used with email automated (mailserver-added) signatures and you change the subject be different kinds of email authorization systems. I'm in fact all for different types of systems and supported wider view of the problem and use of multiple tools (if they don't interfere with each other), but not standardization of closed designs. So what is true is that I did not get it wrong. MASS originally was discussing several authorization methods: public keys in DNS, fingerprints in DNS (and in special HTTP fingerprint server), X509 certificates located on HTTP server and X509 certificate servers. In DKIM however there is left only public key in dns (and talking about other methods would be excluded by means of the working group charter) and I do not believe this issue was ever properly decided on and my argument is that there should be more authorization methods being available (in initial release, otherwise they'd never really get deployed) because public keys retrieval from domain root is too limiting and can not for example fit all scenarios well; plus I think this chosen method is in fact the worst one [based on possible impact to infrastructure] of those available (although it does have large vendor supporting it and only it as usual...) For reference as to how it all occurred you might want to go back one year and glance at http://web.archive.org/web/20050204075618/mipassoc.org/mass/crocker-features-iim-dkeys-09dc.htm and that might make you wonder what is ESTG (care to guess about what this acronym stands for...) which has its own meetings and mail list - http://mipassoc.org/mailman/listinfo/estg-general it was mentioned on ietf too: http://www1.ietf.org/mail-archive/web/ietf/current/msg39474.html BTW - even more interesting message was recently leaked out of it: http://www.mhonarc.org/archive/html/ietf-dkim/2005-12/msg00115.html I'm against doing standardization in limited (and especially private and closed) forums and to me this is what it looks like MASS turned out to be (and I really don't care if this had few long-term IETF folks involved or not). When some SPF folks wanted to do their own standardization group I had some strong comments on their effort too. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Value of Reputation (was Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim))
On Dec 27, 2005, at 7:33 AM, Nathaniel Borenstein wrote: I'm sorry, the authorization method was an echo of the term used in the mail I was replying to (which is why it was in quotes). I was really trying to generalize to a whole range of technologies without making my wording too awkward. Perhaps I should have replaced such methods with antimalware technologies or abuse control mechanisms. In any event, I fully agree that the term authorization, in this context, is both A) insufficiently generalized, and B) troublesome on countless philosophical grounds. The response was specifically against the use of authorization. With respect to SPF/Sender-ID or SSP, these are indeed email-address authorization schemes. With Sender-ID, authorization has been incorrectly described as form of authentication, and much like Sender-ID, SSP appeared more by way of introduction rather than discussion. All of these authorization schemes, especially SSP, will disrupt the delivery of legitimate email. This authorization scheme also proposes untold numbers of DNS lookups for perhaps any number of From addresses and signatures. The art of open-ended authorizations (burden shifting) in SSP will soon include authorized signature lists. SSP also considers itself a weak form of authentication by directing complaints to email-address rather than the signer. : ( Reputation remains the only solution able to abate the bulk of abuse. The word only makes me cringe a bit in any discussion like this (a global fascist state, for example, is another possible solution), but I think most of us pretty much agree about the critical role of reputation. Some view a closed system, rather than a system open to tens of millions of email-address domains, as an alternative to reputation. Even in that austere system however, each would consider their access contingent upon their reputation for good behavior. Reputation is an unpleasant reality where identifying those culpable for abuse _must_ _not_ be taken lightly. I see the cycle as going like this: We need at least one standardized, moderately-useful system for weakly authenticating the sources of messages. I see the base DKIM draft forming a solid basis to identify email sources. The ill considered SSP draft will seriously hinder the DKIM effort. Serious problems are already being handled by way of burden- shifting, rather than considering real solutions. The related expense associated with an imposition of a disruptive email-address authorization scheme does not justify this component's inclusion within the DKIM charter. With far less overhead, spoofing attempts can be thwarted without email-address authorizations. Many of the serious crimes depend upon embedded links rather than use of an email- address (which are never seen by the majority of recipients). A solid basis for the source of an email-address will significantly enhance protective strategies. It is a dangerously false premise that an authorization scheme offers protection, as any assurance in that regard will increase the success rate of criminal fraud. Once we have that, we have the minimal data that a reputation system will require to be able to start doing something at least mildly useful. Please note authentication does _not_ include SSP. Once we have *that*, we will have (in our reputation systems) a built in market for additional systems for (perhaps less weakly) authenticating the desirability (not necessarily solely due to the source) of incoming messages. To some extent, there's a chicken- and-egg problem with authentication and reputation technologies. My hope for DKIM is that it will give us one good enough egg to produce a chicken, which can then (in much the manner that Cain and Abel found their wives, I guess) facilitate a whole new generation of authentication technology eggs. Agreed. Do not let the ill conceived SSP derail DKIM. When reputation is applied against an authorization as an identifier, innocent email-address domain owners will be seriously harmed. Abusers will find acceptance methods for an authorization scheme. Yes, every one of these schemes will be flawed. That is why we need to understand A) the role of weak authentication (weeding out some but not all of the bad guys at any point in time, and using multiple sources of information to judge the desirability of a message) and B) the need for a continually evolving set of (ever- stronger, we hope) mechanisms for proving that a message is desirable to the recipient. Some of those mechanisms will also involve (ever-stronger, we hope) sender authentication, but others could eventually involve technologies as unrelated to authentication as anonymous payment. To ensure email does not self-destruct, use of reputation against authorizations _must_ be avoided as imposing highly unfair
Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
On Fri, 2005-12-23 at 17:27 -0500, Nathaniel Borenstein wrote: 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. There is danger viewing any abuse control mechanism as representing a authorization scheme. The control method should strive to identify the source of abuse, and not just whether the message has been authorized. The DKIM signature provides a fairly strong indication of the message source, with a normal potential for abusive replay as with any cryptographic method. 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. Those who envision SPF or Sender-ID as a means to control spam, clearly have not considered the inherent weakness in an authorization scheme. Bad actors are adept at adopting any such authorization. Reputation remains the only solution able to abate the bulk of abuse. When reputation is applied against an authorization as an identifier, innocent email-address domain owners will be seriously harmed. Abusers will find acceptance methods for an authorization scheme. To abate abuse, name-based identifiers are needed to overcome growing exploits. Reliance upon authorization as an abatement control must be avoided as inherently unfair. The DKIM signature can identify the email source, and when considered independent of any email-address, can establish non-disruptive reputation based abatement controls. A verified EHLO can also serve the same purpose. There are drafts and MTA extensions available today to offer this similar low cost solution. If the desire were really to abate abuse, there is no mystery what can help. CSV, BATV, and the base DKIM would be examples of schemes that can identify email sources. Name-based schemes can significantly reduce the amount of spam when coupled with fair reputation assessments. Authorization is clearly not an abatement solution. Authorization should be seen as a method to shift the burden onto the email-address domain owner. The outcome of an authorization strategy in today's shared environments would likely damage the reputation of most email- address domains. The exception may be for the mega-domains less sensitive to reputation assessments simply due to their size. DKIM should be devised to exist without requiring an authorization scheme to handle message replay or unsigned messages. When MTAs and MUAs are designed to recognize the source of email using DKIM signatures, reliance upon authorization (or reputation) for spoofing protection would be unnecessary. Reliance upon visual examination that often involves acquiring every look-alike domain may also become unnecessary. Recognition ability could be rapidly included in the MTA to offer immediate protections for commonly spoofed domains, while avoiding the disruption an authorization scheme is sure to cause current email practices. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
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 PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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
RE: WG Review: Domain Keys Identified Mail (dkim)
Title: RE: WG Review: Domain Keys Identified Mail (dkim) 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 PROTECTED] on behalf of Keith Moore Sent: Fri 23/12/2005 1:53 AM To: [EMAIL PROTECTED] Cc: John C Klensin; ietf-dkim@mipassoc.org; iesg@ietf.org; ietf@ietf.org Subject: Re: WG Review
RE: WG Review: Domain Keys Identified Mail (dkim)
Title: RE: WG Review: Domain Keys Identified Mail (dkim) 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 PROTECTED] on behalf of Michael Thomas Sent: Thu 22/12/2005 8:18 PM To: John C Klensin Cc: ietf@ietf.org; iesg@ietf.org; ietf-dkim@mipassoc.org 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
Nathaniel Borenstein [EMAIL PROTECTED] wrote: On Dec 21, 2005, at 12:23 PM, william(at)elan.net wrote: 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. Well, that may not be what you're arguing about, but it's certainly what I'm arguing about, at least at the present moment. The language under debate doesn't impact the question you raise one way or the other. The first paragraph of the charter quite clearly states that the WG will be working on domain-level signatures. So, the language under debate is purely about ruling out incompatible changes that still fall along these same general lines. 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, Then why the push to have charter language designed to do exactly that? -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Branching off from the interminable justifiable changes thread --On onsdag, desember 21, 2005 23:54:56 -0800 Cullen Jennings [EMAIL PROTECTED] wrote: Related to how much the charter pre-supposes the solution, the sentence that Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. seems like a pretty heavy constraint on the possible solutions and one that some proposals disagreed with. I think this is part of divide and conquer that is generally argued to be an useful strategy in the IETF: once we buckle down and start writing specs, we're documenting one approach, with one set of advantages and disadvantages, and are trying to prove that *this approach* is feasible. We did that to (I believe) OSPF, IPNG after the pick one round, PKIX (vs SPKI), IM when it was split into SIMPLE and the 2 alternatives (with XMPP being a late 4th) and so on. Each of these groups could regard the what are the alternatives question as out of scope. I think that's a good way to get things out the door in a reasonable timeframe; I also think that the IETF at the moment lacks venues for the (probably interminable) discussions about what approaches to a problem exists and whether there are non-chartered alternatives that are worth following up - but I think the approach of chartering a WG to look at one and only one approach is a reasonable one. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Related to how much the charter pre-supposes the solution, the sentence that Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. seems like a pretty heavy constraint on the possible solutions and one that some proposals disagreed with. I think this is part of divide and conquer that is generally argued to be an useful strategy in the IETF: once we buckle down and start writing specs, we're documenting one approach, with one set of advantages and disadvantages, and are trying to prove that *this approach* is feasible. Sometimes feed-forward _is_ useful, and I would agree that the use of DNS to store public key information is one of the fundamental assumptions behind DKIM. Change that assumption and you will probably produce a system with very different characteristics than DKIM is currently assumed to have. OTOH, the assumption that _all_ public keys used to validate DKIM signatures will be stored in DNS is a very limiting one, because it appears to lead to either a) a constraint that policy be specified only on a per-domain basis (which is far too coarse for many domains) or b) a situation that large numbers of DNS queries may be required to validate a single signature I'm comfortable with having a domain's root public keys stored in DNS but allowing the corresponding root private keys to sign key certificates for individual public keys that can be included in DKIM-signed messages. The policies for use of those public keys can then be encoded in the certificates, allowing those policies to be specified on a per-user basis. This gets out of the trap of having to specify policy on a per-domain basis, and doesn't require any more DNS queries than current DKIM. IMHO it would make DKIM much more flexible and adaptable to diverse domain situations (and thereby much more acceptable as a standard) than the current proposal. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Keith, Keith Moore wrote: I'm comfortable with having a domain's root public keys stored in DNS but allowing the corresponding root private keys to sign key certificates for individual public keys that can be included in DKIM-signed messages. The policies for use of those public keys can then be encoded in the certificates, allowing those policies to be specified on a per-user basis. This gets out of the trap of having to specify policy on a per-domain basis, and doesn't require any more DNS queries than current DKIM. IMHO it would make DKIM much more flexible and adaptable to diverse domain situations (and thereby much more acceptable as a standard) than the current proposal. If there were an I-D describing such a protocol, I'd be interested in reading it - is there one? Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
The question that I think IESG should be asking themselves is how is this similar and/or different from other groups the have chartered or will in the future. Nearly every group has some people with a fairly strong idea of at least one way to solve the problem. Without this, it is usually not clear the work is even possible. Now some groups, XMPP for example, perhaps TLS long ago, have substantial deployment with difficult backwards compatibility questions - theses situation might require the charter to provide more than normal limitations to the scope of the solutions that are possible. I'm failing to see that dkim has existing deployments or difficult backwards compatibility problem that would cause the need for some special text in the charter more than you average WG. The need for special text is not due to existing deployments or backwards compatibility problems; it is due to the existence of a small number of individuals who have a history of arguing quite forcefully that certain design decisions are carved in stone, despite the problems caused by those decisions and the lack of any working group consensus on those decisions. Said individuals have also been known to make misleading statements to support their arguments. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
If there were an I-D describing such a protocol, I'd be interested in reading it - is there one? Not yet. But it hardly seems like the time to write an I-D when there is at present considerable effort being invested to preclude such an I-D being considered by the group. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Branching off from the interminable justifiable changes thread Dropping DKIM, because those people suffer enough without being subjected to more general discussion about the nature of the universe at IETF :-) I applaud Cullen for his note. I agree with the parts that Harald snipped out, too (I'm just trying to post below the thread branch, so followups stay together). I think that's a good way to get things out the door in a reasonable timeframe; I also think that the IETF at the moment lacks venues for the (probably interminable) discussions about what approaches to a problem exists and whether there are non-chartered alternatives that are worth following up - but I think the approach of chartering a WG to look at one and only one approach is a reasonable one. The analogy I've been using in private e-mail discussion on how new work comes into the IETF is that the IETF is a bakery that's become pretty difficult to enter with only a bag full of raw ingredients, but if people bring in a finished cake with frosting and just ask for a boz to put the cake in, we're not a bakery any more. It really is a problem that (as Harald says) we don't have a good place to discuss alternative solutions, given that we are trying to be an engineering task force that may also standardize protocols, not a protocol standardization task force that occasionally tries to engineer something. People who need to solve a problem have every incentive to deploy what they believe is a solution to their problems as soon as they can specify it. The more specification work that happens on the way to the IETF, the more likely that work is to be deployed while we are discussing charters, the more pushback we see on charter discussion, and the less likely a second-round version of the protocol is to be widely deployed. I'd also like to point to Thomas Narten's draft on how to run a successful BOF (currently http://www.ietf.org/internet-drafts/draft-narten-successful-bof-00.txt). I would like to see some changes considered for the way we bring new work into the IETF, but getting a baseline on how it works today is a critical first step. I have provided a page or two of comments to Thomas, CC: Brian as General AD, and hope that others also look it over and provide feedback (soon) Thanks for reading, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Said individuals have also been known to make misleading statements to support their arguments. I'm thinking we must be coming to the end of productive discussion... Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Thu, 22 Dec 2005, Keith Moore wrote: Sometimes feed-forward _is_ useful, and I would agree that the use of DNS to store public key information is one of the fundamental assumptions behind DKIM. Change that assumption and you will probably produce a system with very different characteristics than DKIM is currently assumed to have. Not necessarily. One of the proposals that went into DKIM had characteristic of storing public key fingerprints in dns. This seems quite close to DK but has a number of advantages and unlike DKIM or DK does not put serious extra pressure on DNS infrastructure - which while very capable of serving data like ip addresses (i.e. fixed size small data) would not work so well for when data served answer would either come close to or exceed 512bytes UDP limit. But fingerprints (hash of public key) are finite and small pieces of data that are the same size no matter of public key size has to be larger or smaller and with this size being close to that of ipv6 address. Additionally having public key available with a message brings some additional advantages and allows for optimized algorithms during verification. As I noted the group forcefully removed considerations of such alternatives based on the charter and I consider this to be a disadvantage to community. OTOH, the assumption that _all_ public keys used to validate DKIM signatures will be stored in DNS is a very limiting one, because it appears to lead to either a) a constraint that policy be specified only on a per-domain basis (which is far too coarse for many domains) or b) a situation that large numbers of DNS queries may be required to validate a single signature Its rather likely that it would lead to both. I'm comfortable with having a domain's root public keys stored in DNS but allowing the corresponding root private keys to sign key certificates for individual public keys that can be included in DKIM-signed messages. The policies for use of those public keys can then be encoded in the certificates, allowing those policies to be specified on a per-user basis. You can just use X.509 certificates and retrieve them from HTTP with SRV records being used to confirm location of domain's root certificate. That walso one of the other alternatives (and the one I used for my proposal) and yes, it does make it much easier to do per-user policies signatures. This gets out of the trap of having to specify policy on a per-domain basis, and doesn't require any more DNS queries than current DKIM. IMHO it would make DKIM much more flexible and adaptable to diverse domain situations (and thereby much more acceptable as a standard) than the current proposal. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Thu, 22 Dec 2005, Barry Leiba wrote: Actually, the DKIM base spec does provide a mechanism for replacing the DNS keystore with something else. Look at 1.4 for a general statement, and the description of the q= tag in 3.5. DKIM's intended to be able to support user-level keys in a future version (there's some discussion of that in appendix A), and its design is set up specifically not to prevent that. The spec basicly says that you must support DNS public key distribution and authorization; that something else may also be added later will not change requirement for pki in dns and will only be usefull for those who can support it as alternative way to retrieve the key (which means the key would still need to be made available through dns for those who do not). It is really no brainer to see that if we have several authorization meachanisms a set of them would have to be done as a required for those creating implementation in order for them to be used and that means working on all that as part of the main work on the system and releasing together with other documents on the signature system. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
Keith Moore wrote: OTOH, the assumption that _all_ public keys used to validate DKIM signatures will be stored in DNS is a very limiting one, because it appears to lead to either a) a constraint that policy be specified only on a per-domain basis (which is far too coarse for many domains) or Actually, the DKIM base spec does provide a mechanism for replacing the DNS keystore with something else. Look at 1.4 for a general statement, and the description of the q= tag in 3.5. DKIM's intended to be able to support user-level keys in a future version (there's some discussion of that in appendix A), and its design is set up specifically not to prevent that. The proposed charter puts the details of other key management systems and user-level keys out of scope so that we can contain the work at this stage, and make quick progress on the first version. It'd be entirely reasonable to recharter and attack these issues immediately after completing the first round of chartered work, if there are enough people who want to work on that. Or we can see how a while of deployment goes, and form another WG in a year or so to do it. I disagree. The first standard version of DKIM needs to be something that is broadly applicable, not something that just handles a few corner cases. The amount of stress associated with getting closure and consensus on a document is sufficiently large (independent of the document scope) that it doesn't seem like a good idea to waste all of that effort producing a first document that is of limited applicability, and that will need to be updated soon - particularly when a lot of the division within the group stems from the current DKIM spec's overconstraining the problem. If your goal is gaining consensus on a useful specification in the shortest amount of time, it makes far more sense to work on the different aspects of the problem in parallel rather than serially. Let one subgroup work on per-domain keying, key management, and policies; another subgroup work on per-user keying, key management, and policies; another subgroup work on message canonicalization; another subgroup work on specifying signature and hash algorithms (and managing the transition from weaker to stronger algorithms as these are discovered); and finally, have a coordination team responsible for making everything fit together and managing the framework (definitions, header field names, parameter names, keywords) that all of these pieces fit into. Give each subgroup a year, with deliverables at 4 month intervals. After a year, expect to do working group last call on all pieces and start polishing the drafts for final publication. If any piece proves to be unworkable, it can be thrown out after a year. But even if that piece needs to be replaced from scratch and this causes a delay that's better than imposing a serial dependency a priori. The unworkable piece could as easily be per-domain keying as per-user keying. I believe this approach will produce a consensus far more quickly than the serial approach, and that the resulting standard will be more broadly applicable and more robust. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
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. Mail is, in fact, pretty different than most IETF protocols insofar as it's a store and forward system where there can be no expectation of end to end negotiation which is generally helpful for smoothing out protocol botches and incompatible changes. With mail every time you make an incompatible change, you have to hope that the receiver at the far end is in synch with that incompatible change or you're pretty well hosed. With each one the utility of the protocol is divided and conquered. 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 is that there is a sufficiently high barrier that cosmetic changes not be good enough reason to make a backward incompatible revs. Equally disasterous would be to throw this entire area open for a greenfield design; considerable time and effort has been expended, and frankly Keith's observations don't strike me as new or novel -- we've been at this for many years at this point, and his points have been hashed and rehashed many times over the years by the people who have been paying attention to this more than just the week before and after a BOF. Mike ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Michael, Nice note. One point, however: Michael Thomas wrote: 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 We have agreed to the addition of an enhancement that provides a good alternative to the existing set of two algorithms. That is quite different from tossing out over-the-wire backward compatibility. I have not seen the group agree that a sender of an (ESTG) DKIMv1 signature will fail with an (IETF) DKIMv2 validator. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Dave Crocker wrote: We have agreed to the addition of an enhancement that provides a good alternative to the existing set of two algorithms. That is quite different from tossing out over-the-wire backward compatibility. I have not seen the group agree that a sender of an (ESTG) DKIMv1 signature will fail with an (IETF) DKIMv2 validator. Dave, 'nowsp' canonicalization does not exist in DKIMv2 (-base-01). It was eliminated, rather than deprecated, because it created a vulnerability. While some -base-01 verifiers may implement legacy nowsp support, a fully compliant -base-01 verifier may not work with a -base-00 signature that uses nowsp canonicalization. -Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Dec 22, 2005, at 8:38 AM, Keith Moore wrote: If your goal is gaining consensus on a useful specification in the shortest amount of time, it makes far more sense to work on the different aspects of the problem in parallel rather than serially. My concern regarding the charter is related to inclusion of the SSP draft, which can impose significant disruption. In my view, DKIM should be seen as aspect of the SMTP transport. Having a signature at the transport qualifies sources of email, but should not constrain use email-addresses. Schemes related to the email-address such as S/ MIME or OpenPGP are designed to support email-address limitations. On the other hand, DKIM purports to offer S/MIME or OpenPGP like features for a sub-set of domains willing to disrupt normal email practices. The premise for DKIM protection assurances is based upon visual examination of the email-address. This seriously flawed concept already demands most MUAs change. Even the body-length option pre- supposes there is some type of MUA modification. With DKIM sans SSP, the MUA would be able to recognize prior correspondents without any other exchange of information. In some cases, an MTA could use this recognition to exclude some abusive traffic based upon prior recognitions. The MUA should be able to safely signal source recognition, but signaling adherence to some authorization would only place recipients in peril. SSP, just as with Sender-ID, requires email-address domain owners authorize the source of their email, where signatures are transposed for address lists. To allow existing practices, open-ended authorizations are required. The danger from this approach has been made apparent by those willing to hold any sort of authorization accountable for abuse seen. There can be no promise that authorizations can be open-ended to support existing practices. Reputation schemes bolstered by having authenticated the identifier when finding an authorization record will quickly preclude use of open-ended authorizations. When only a few domains publish the closed-ended authorization records for SSP, looking for policy for the majority of email will then require that label trees be climbed, where none of this effort can be effectively cached. The solution for this rather broken strategy is to create records that indicate open-ended authorizations to mitigate the search. These nonsense open-ended records however expose the email-address domain owner to unfair reputation schemes already in place. Details have been published for compatible extensions to DKIM that improve upon source recognition, abating abusive message replay, locating compromised systems, limiting the number of signatures per message, establishing expectations for specific email-addresses being signed, without requiring any additional lookups in most cases. http://www.sonic.net/~dougotis/id/draft-otis-dkim-options-00.txt The WG should be limited to establishing the base DKIM signature. This signature should be viewed as an aspect of the SMTP transport to differentiate it from S/MIME and OpenPGP. Another WG should make efforts related to the MUA incorporating the protections offered by DKIM in an opportunistic fashion. In essence, everyone becomes their own certificate authority based upon individual email source identifiers offered by DKIM. Recipients would be able to confirm the validity of the correspondent through out-of-band identifications of the source. This could be simply an expected confirmation when initially establishing a relationship. Once the initial identifier has been accepted by the recipient, messages could be safely highlighted as coming from a recognized source. There can never be a safe indication based upon a domain used in the email address as having authorized the message. There must be more consideration given for the use of unicode. One only needs to investigate the number of look-alike characters in Chinese to understand the fallacy of that assurance. Even the individual that does not understand the difference between online.bigbank.com and online-bigbank.com could be protected by a recognition scheme. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
'nowsp' canonicalization does not exist in DKIMv2 (-base-01). It was eliminated, rather than deprecated, because it created a vulnerability. sorry. i had misunderstood that line of discussion. and, yes, vulnerability counts as a showstopper. While some -base-01 verifiers may implement legacy nowsp support, a fully compliant -base-01 verifier may not work with a -base-00 signature that uses nowsp canonicalization. ack. that still leaves useful over-the-wire compatibility, doesn't it? d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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.
Re: WG Review: Domain Keys Identified Mail (dkim)
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. 2. This misrepresentation of things has been asserted repeatedly and has been correctly repeatedly. 3. At this stage, repeating this misrepresentation has taken on the characteristic of willful distortion. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
--On Thursday, 22 December, 2005 14:09 -0800 Dave Crocker [EMAIL PROTECTED] 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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote: Not necessarily. One of the proposals that went into DKIM had characteristic of storing public key fingerprints in dns. This seems quite close to DK but has a number of advantages and unlike DKIM or DK does not put serious extra pressure on DNS infrastructure Unproved speculation. As you know, email, compared to HTTP and P2P (neither of which sought approval from the IETF) constitutes an increasingly tiny part of the Internet load these days. The serious pressure comes from applications that never came near the IETF. like ip addresses (i.e. fixed size small data) would not work so well for when data served answer would either come close to or exceed 512bytes UDP limit. Unproved speculation. As you know, 512 is not a UDP limit it's a DNS implementation limit which was long ago removed by EDNS0 - an IETF standard. The other minor matter is that the Internet is already participating in a billion+ DK signed and verified emails per day - I've been watching, but as yet, no news at 11. At what point do you expect the pressure to be noticed? William. I admire your interest in optimizing DNS load, but, as Knuth might ask, is it premature? If you think not, convince us otherwise. Mark. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Pre-picking one solution (Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail) (dkim)
On Fri, 23 Dec 2005, Mark Delany wrote: On Thu, Dec 22, 2005 at 06:35:47AM -0800, william(at)elan.net allegedly wrote: Not necessarily. One of the proposals that went into DKIM had characteristic of storing public key fingerprints in dns. This seems quite close to DK but has a number of advantages and unlike DKIM or DK does not put serious extra pressure on DNS infrastructure Unproved speculation. As you know, email, compared to HTTP and P2P (neither of which sought approval from the IETF) constitutes an increasingly tiny part of the Internet load these days. The serious pressure comes from applications that never came near the IETF. That is not a proper comparison. DNS is a key protocol (not to be confused with protocol for keys :) for almost all other L7 protocols on the net. HTTP was just another protocol and its use would not have had much effect on say telnet or ftp (ok, for ftp it might as it began to be used as replacement, but that is different matter). We have to be a lot more careful what we choose to do with dns and I think it should stay primarily as a protocol for linking domain names. to specific data locations rather then becoming all-purpose database. Another issue is that dns is not just client-server protocol where impact of using it would only be limited to server that chose to deploy dkim records and client that chose to check it. My view is that there is enough uncertainty and that if load on [core] protocol like dns can be minimized and moved into specific L7 protocol like SMTP, that it should be done. And we do have easy enough way to do it with DK-like system by using fingerprints. like ip addresses (i.e. fixed size small data) would not work so well for when data served answer would either come close to or exceed 512bytes UDP limit. Unproved speculation. As you know, 512 is not a UDP limit it's a DNS implementation limit which was long ago removed by EDNS0 - an IETF standard. Nevertheless for immediate future [at least 5 more years, probably 10] 512bytes is basically limit that dns records should fit in. BTW - that case of adding EDNS extension to widely deployed system and how slow long it takes to do is an example why adding additional key authorization methods to DKIM would not be easy and why we should worry about this issue right now. The other minor matter is that the Internet is already participating in a billion+ DK signed and verified emails per day - I've been watching, but as yet, no news at 11. At what point do you expect the pressure to be noticed? The number of emails being signed and checked is actually the main factor - especially for sites that constantly communicate with each other. What would make a difference is large number of small domains that only occasionally send emails but would have a signature on them requiring checking dns and caching the public key (I predict that specialized optimized caching servers would be needed - in fact its somewhat in my area so I may even make good money if we all have this requirement ...) Also small mail servers that have to check all signed emails would see these issues in even greater degree. What would also make a difference is when users at the largest domains begin to demand to be able to use their own unique keys. William. I admire your interest in optimizing DNS load, but, as Knuth might ask, is it premature? If you think not, convince us otherwise. Nothing is premature when it comes to dns. Once you make mistake its difficult to fix (without impacting ongoing deployment) even if other services are known to be impacted. As I said, it comes down to that we do have other choices to putting large records in dns and they are basically close to being equivalent to public keys in dns, so we should choose those. At the very least make them available as core supported authorization methods so in the future if problems are found, there would be a backup plan that does not require upgrade of every site software. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
John, 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 Please provide quotes, and please reconcile your assessment with the list of real changes already made or agreed to. 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. Wow. I have no idea what you are talking about or what you are basing it on. 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, 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. Gosh, yes. You are right. It is entirely unreasonable to object to the change here. 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. Helpfulness requires that a problem exist. It didn't. When the purported helpfulness is in response to an artificial problem created by the purported helper, things look a lot more like Munchausen by Proxy. 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. You must be basing that assessment on some bit of conjuring that has nothing to do with what I have actually said, since you are quite simply wrong. 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. Groundswell? Again, wow. John, have you bothered to count just how few people are unhappy with the existing language? And please distinguish unhappy from willing to go along with a change in order to get the charter approved. Have you bothered to compare your purported groundswell with the number of participants who contributed to developing the existing text? And, yes, it is worth noting that two of the active objectors are IETF management folks, conducting a sour-grapes campaign, since they failed to gain support during the open charter development discussions. Their efforts are all the more intriguing given that neither of them has ever cited a specific working group task that is likely to be needed but would be prevented. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Ted, Ted Hardie wrote: I believe the text here: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. implies the need to be clarify the charter in two ways. The charter needs to reaffirm that the IETF has change control over the specifications at this point, so that there is no question over who gets to decide whether an incompatible change is necessary. I think that this is motherhood and apple pie, and would have no objection to inclusion of a reasonable statement along these lines. But it might take a while to agree what's reasonable and since Dave's right that this would be a kind of impactless change to text that did take some time and effort already, I'd rather not have a prolonged discussion on the topic. Meanwhile, as a point of fact, the DKIM specification has already changed in one on-the-wire incompatible way (canonicalisation), as a result of a bug. I also expect another wrt. hashing since sha-1 is probably not the right thing to use anymore. So, there is an existence proof that the current set of authors are willing to change the specification in response to review. (The suggestion that all charters have some implicit boilerplate that'd include such IETF change control phrasing does sound like a reasonable thing to discuss sometime.) The charter also needs to indicate that the working group will consider the relationship of this work to other, existing IETF technologies. That does not imply that it needs to adopt them, but explaining why it chose to use, for example, this signature mechanism rather than one of the existing ones would help the IETF understand whether this mechanism is a better point solution, implies a problem with the existing mechanisms which should be fixed in the existing solutions, or should be considered as the basis of a more wholesale replacement. Just checking. You're referring to the why not s/mime question here, right? I think answering that question is reasonable (and has a good answer). The putative DKIM WG is not however the place to expect an answer to why don't we all use s/mime as I'm sure you agree. Its quite possible that answer to the first question might help answering the second one, but I wouldn't want to raise too many expectations. (BTW I fully agree with what Barry said on this too.) Doing so in its first milestone document seems like a reasonable way to accomplish this, but doing so in the standards-track specifications also seems reasonable. Well, we included an overview deliverable which is intended to capture all that kind of stuff. Its the last deliverable but of course that doesn't mean that that particular piece of text won't exist earlier. If you're thinking that the IESG might want to see/discuss the why not s/mime answer during IETF last call on the protocol spec, I guess that's reasonable. Requiring that that answer be part of the last-call document or the threats document doesn't seem like the best way to handle this though. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Hi Eric, Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. As I argued on the DKIM working group list, I think this text is a bad idea. Part of IETF having change control of a specification is having the ability to make changes, and the bar of necessary to the success of the specification is way too high for that. Note that I'm not suggesting that the WG shouldn't consider compatibility, merely that it shouldn't be effectively prohibited by charter from making incompatible improvements. I don't read that as prohibiting incompatible changes, since canonicalisation and hashing are two such changes. Incompatible improvements that are not bug-fixes are discouraged though, and I can see how that raises concerns. I can also see how apparently encouraging incompatible improvements that are not bug-fixes raises concerns. Personally, I think each on-the-face-of-it-reasonable suggested improvement has to be considered, but the more time passes and the more the specifications are mature, the higher the bar is raised. Since these specs. have been around a while and have been implemented it seems reasonable to start this WG with a higher bar than one where neither of those things are true. Its obviously tough to write text saying the above that makes everone happy since there are so many subjective aspects involved. Clearly though (as pointed out) a new rough consensus has to be established in the WG, and subsequently during IETF last call and I do expect that process to involve questioning the design decisions which were made prior to the WG getting started. Whether such questioning results in changes (compatible or otherwise), is something we can't know at this stage. I'd also note again that compatible with what's deployed doesn't (once you've changed canonicalisation, which has happened already) mean the same as on-the-wire compatible, so the current text is actually less constraining than might seem to be the case at first reading. Lastly, the text does say that the working group will not be unreasonable in attempting to maintain compatibility, so as the Marx brothers said, there is a sanity clause after all:-) Basically, I think the current text is ok, even if it looks a bit scary. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
--On Tuesday, 20 December, 2005 18:50 -0800 Dave Crocker [EMAIL PROTECTED] wrote: Having this point in this charter mostly serves as a statement of mistrust, rather than providing any useful education or constraint. ... Adding such a statement is all about education. It is perfectly reasonable to not trust that newcomers will understand IETF policy; heck, many folks who have been active for years don't. 1. You said you disagreed, but then provided an argument for not trusting participants (people who do not understand the IETF rules.) ... Dave, As I am sure you will recall, I've been very concerned since you first proposed this about the notion of a WG that starts on the assumption that almost all of the work is done and proven in the field and that the IETF's role is limited to fine-tuning that really does not change anything... unless the feature to be changed is definitively proven to not work. I believe that, in situations that are superficially similar, my colleague Dave Crocker has argued that the IETF should not take on the work at all because there is no value added other than endorsement. But perhaps my memory is bad or this situation is subtly different. It seems to me that you and your colleagues have asked for a charter constraint that asserts wide deployment and, on that basis, appears to constrain the choices and changes the IETF can make. I am sympathetic to the desire for that constraint but I think we all need to accept that it is an unusual request. Because it is unusual, it also seems to me that (i) you are obligated to demonstrate that sufficient production-level deployment actually exists to justify such a request and that it has been successful in solving whatever problem the proposed work is intended to solve. Normally, that would be a ridiculously onerous requirement to place on a charter proposal for a WG. But, because this effort has requested --and written into the draft charter-- some unusual restrictions on the IETF on the basis of the deployment level, the situation, IMO, changes: if you want or need the restrictions, then you should be willing to accept the added scrutiny and text. While I am convinced that a great deal of effort, collaboration, and compromise have gone into the current proposals, I have yet to see evidence of significant and successful deployment. (ii) this WG proposal and several of your recent comments request that IETF give up most design control --including the ability to determine whether the need for a change is significant enough to be considered -- before (from an IETF process standpoint) the effort has started. I completely agree with you about the difference between broken and maybe could be made better and the importance of understanding where to draw the line. But the intent of this charter appears to be to vest the decision about what changes are appropriate (or not) entirely in the self-designated leadership of the WG, placing constraints on the usual processes of review and interactions. It is reasonable, IMO, for the IETF to respond by including in the charter things that would be obvious were the WG more normal and conventional, and even to impose some extra conditions that would be unusual for a more conventional WG setup, simply to stress that those elements of WG operation and review had not changed. (iii) you are obligated to be quite explicit about the value added by IETF involvement given those constraints, much more explicit that would be expected of a normal WG that had not requested the constraints. There is certainly a case to be made that the push-back you are getting would be unreasonable were this a conventional WG charter proposal. But, because of the request for constraints on permitted changes, it is not a conventional WG charter proposal and suggestions about additional review, additional constraints, and specific additional language all seem to me to be appropriate as a result. 2. You cannot seriously think that adding the language Ted suggests -- [...] -- will make any difference to the working group process. Viewed in the light of the above, some language along the lines I think Ted and others have suggest might actually be quite valuable in delineating how far the WG (or its leadership) is expected or permitted to go in application of the requested restricted changes principle. Such language could be useful in documenting an agreement, setting expectations, and preventing future misunderstandings. Should it be the community's expectation that having such agreements, and having them documented, would not make any difference to the working group
Re: WG Review: Domain Keys Identified Mail (dkim)
the IETF has done work on message signing before, and some of those earlier efforts (like CMS in detached signature mode) look enough like pieces of DKIM that there is question of whether DKIM not using them indicates that they do not work, that this message signing is a better point solution, that this message signing mechanism would be better over all, or none of the above. I believe the discussion Ted suggests IS in scope for the working group we're proposing to charter, and I don't believe that the charter text in question affects that. It will be up to the WG chairs to judge rough consensus on the discussion, or to decide, should it happen, when the discussion has become fruitless and wasteful of the WG's time, especially considering the short schedule that's proposed. If Russ should choose me as a co-chair of the DKIM WG, be assured that we WILL have this discussion. Be also assured that I won't let it turn into a rathole and impede progress. I believe that is the balance that has to exist in any WG, and that the ADs place a good deal of trust in the WG chairs to both allow discussions that ought to happen, and control discussions so they stay within the scope of the WG and do not get out of hand. I don't think that anything we say in the charter changes this; it is meant to provide a guide for resolving the ratholes and distractions. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. As I argued on the DKIM working group list, I think this text is a bad idea. Part of IETF having change control of a specification is having the ability to make changes, and the bar of necessary to the success of the specification is way too high for that. Note that I'm not suggesting that the WG shouldn't consider compatibility, merely that it shouldn't be effectively prohibited by charter from making incompatible improvements. I hear you, Eric, and, yes, we've all discussed this at length before. There are people with opinions at both extremes on this (from we must leave that paragraph unchanged to we must remove that paragraph completely). For my part, as the current editor of the charter, I'm happy with a change in the text if we can get consensus on some text that will make both sides at least somewhat happy (or perhaps I should say somewhat less unhappy). We weren't able to do that on the ietf-dkim list before the BOF. Let's try to spend a little time doing that now (keeping in mind the realities of the IETF process, and that the charter can not bypass that process, nor is it trying to). We have more eyes and more fingers now, and perhaps someone new can craft text that will work. Experience in this area (anti-spam-related things) shows us that we DO need strong guidelines to stay on track, and I believe that weakening the wording too much does not provide us with those guidelines. As I said in in my other post, just sent, it's really the job of the WG chairs to deal with this. Still, strong guidelines make it easier for the chairs to do their jobs efficiently, and for the ADs to handle escalations effectively. Can someone propose an alternative to the first-quoted paragraph above, from the proposed charter, that keeps the sense that the specifications we're agreeing to use as a starting point be strong conflict-resolution guides, and that they be used to steer the discussion... without making it seem, incorrectly, that the WG is not willing to accept changes that make sense to make? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
On Wed, 21 Dec 2005, John C Klensin wrote: (i) you are obligated to demonstrate that sufficient production-level deployment actually exists to justify such a request and that it has been successful in There is no wide deployment of DKIM. What is there are several test machines on the order of couple dozen. There is larger deployment of DK on the order of several hundred active mail servers doing signing (including some large ones like outgoing webmail servers @yahoo google; DKIM is different and they all have to change anyway), but it does not even closely comes to something that can be said to be wide deployment or existing protocol. What is there however is a lot of hype and marketing created by Yahoo and associated organizations about DK DKIM being a solution to SPAM (which as we know is not really true). I do not think it's that good when marketing is being used to justify going against IETF normal procedures and instead of working out system on public MASS WG as originally planned, to go around IETF and create proposal in private and then present to IETF for a stamp of approval. I also think that if allowed to be presented alternatives to putting public keys in DNS, those would technically be found superior and less damaging to internet. Other aspects of proposal also had alternatives that are superior, but by bypassing MASS and presenting DKIM in current form with constraints on discussion, all that mess is avoided. No matter if we end up with good system or not, I believe in the end IETF and internet in general lost on how it all happened because IETF showed that it can be fairly easily manipulated and for Internet there is no guarantee that what comes out as standard is technically best approach to solve the problem and that such approach is really vendor-neutral in how it was conceived. But perhaps that marketing wins over technically best is how it really works in the real life of corporate business (i.e. think about why Microsoft products are used) and that is not as bad as I think that IETF is being put inline with such vendor-dominated business world. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
I would be happy with the text that was used in the xmpp charter: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. This text still keeps the bar high for unnecessary changes, was already vetted through an existing charter, and helped us through a similar impasse when xmpp was chartered. Tony Hansen [EMAIL PROTECTED] Barry Leiba wrote: Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. Can someone propose an alternative to the first-quoted paragraph above, from the proposed charter, that keeps the sense that the specifications we're agreeing to use as a starting point be strong conflict-resolution guides, and that they be used to steer the discussion... without making it seem, incorrectly, that the WG is not willing to accept changes that make sense to make? Barry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
John, As I am sure you will recall, I've been very concerned since you first proposed this about the notion of a WG that starts on the assumption that almost all of the work is done and proven in the field and that the IETF's role is limited to fine-tuning that really does not change anything... 1. fine-tuning that really does not change anything is a mis-representation of what I have described. 2. I did not propose anything. I noted that the transfer of existing technology into the IETF has an inherent issue with deciding whether to protect existing work and how much to protect it, and I noted that this is a long way from the first time the IETF has chosen to protect quite a bit. 3. What work do you want to have done by the working group that is prohibited by the the charter language in question? I believe that, in situations that are superficially similar, my colleague Dave Crocker has argued that the IETF should not take on the work at all because there is no value added other than endorsement. But perhaps my memory is bad or this situation is subtly different. or perhaps not so subtly. Does superficially similar mean not really similar? In any event, I'm sure you can substantiate your claim, here. It would be a shame for such an assertion not to be amenable to deeper evaluation. It seems to me that you and your colleagues have asked for a charter constraint that asserts wide deployment and, on that I believe the language that has been used does not match the language you are using. (i) you are obligated to demonstrate that sufficient production-level deployment actually exists to justify John, if you do not care about 2 years of prior technical, development and deployment prior work, then please simply say so. If you do not care about 5 months of open-participation discussion and revision to the charter that reached rough consensus on the draft charter text *twice*, then please simply say so. Welcome to the modern IETF. Infinite time to raise abstract principles, absent any specific technical concerns. No time to focus on concrete work. An excellent productivity disincentive for the community. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
--On onsdag, desember 21, 2005 05:36:08 -0800 william(at)elan.net [EMAIL PROTECTED] wrote: I also think that if allowed to be presented alternatives to putting public keys in DNS, those would technically be found superior and less damaging to internet. Other aspects of proposal also had alternatives that are superior, but by bypassing MASS and presenting DKIM in current form with constraints on discussion, all that mess is avoided. My usual immediate response to anything that contains the phrase allowed to be presented is where's the draft. MASS had its BOF and its mailing list, so I'm assuming that whoever participated in that discussion discovered the fact that they could publish an internet-draft for ANYTHING without prior approval, as long as it was done in their own name and not in the IETF's. So in this case, the drafts might actually be out there. If so - what's the draft names? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
On Wed, 21 Dec 2005, Harald Tveit Alvestrand wrote: --On onsdag, desember 21, 2005 05:36:08 -0800 william(at)elan.net [EMAIL PROTECTED] wrote: I also think that if allowed to be presented alternatives to putting public keys in DNS, those would technically be found superior and less damaging to internet. Other aspects of proposal also had alternatives that are superior, but by bypassing MASS and presenting DKIM in current form with constraints on discussion, all that mess is avoided. My usual immediate response to anything that contains the phrase allowed to be presented is where's the draft. Yes, the drafts and proposals were published as part of MASS. I have links to most of that at: http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm 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 (i.e. public keys in dns; it so happens that public keys in dns is also core of the Yahoo's patent and other authorization method do not have such IPR constraints). And yes in case you don't know BoF chairs and AD did deny request to present alternatives to DKIM when it was still called MASS BoF. MASS had its BOF and its mailing list, so I'm assuming that whoever participated in that discussion discovered the fact that they could publish an internet-draft for ANYTHING without prior approval, as long as it was done in their own name and not in the IETF's. So in this case, the drafts might actually be out there. If so - what's the draft names? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
At 9:07 AM -0500 12/21/05, Tony Hansen wrote: I would be happy with the text that was used in the xmpp charter: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. This text still keeps the bar high for unnecessary changes, was already vetted through an existing charter, and helped us through a similar impasse when xmpp was chartered. Tony Hansen [EMAIL PROTECTED] I agree with Tony on the benefits of re-using this language, and it certainly works for me. I'd also like to thank Stephen Farrell for pointing out the overview document as a logical place to answer the relationship to other IETF technologies questions. The current language for that work item says: An informational RFC providing an overview of DKIM and how it can fit into overall messaging systems, implementation and migration considerations, and outlining potential DKIM applications and future extensions. I suggest adding how it relates to other IETF message signature technologies. Given that this document already discusses other potential DKIM applications and future extensions, Stephen is right that the discussion fits here better than either place I earlier suggested. regards, Ted Hardie Barry Leiba wrote: Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. Can someone propose an alternative to the first-quoted paragraph above, from the proposed charter, that keeps the sense that the specifications we're agreeing to use as a starting point be strong conflict-resolution guides, and that they be used to steer the discussion... without making it seem, incorrectly, that the WG is not willing to accept changes that make sense to make? Barry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
As I argued on the DKIM working group list, I think this text is a bad idea. Part of IETF having change control of a specification is having the ability to make changes, and the bar of necessary to the success of the specification is way too high for that. Note that I'm not suggesting that the WG shouldn't consider compatibility, merely that it shouldn't be effectively prohibited by charter from making incompatible improvements. I hear you, Eric, and, yes, we've all discussed this at length before. There are people with opinions at both extremes on this (from we must leave that paragraph unchanged to we must remove that paragraph completely). For my part, as the current editor of the charter, I'm happy with a change in the text if we can get consensus on some text that will make both sides at least somewhat happy (or perhaps I should say somewhat less unhappy). Consensus on the charter would of course be a good thing, but it's not a necessary condition. The job of the charter is to appropriately direct and focus the group's work, not to make everyone happy. Also, the WG may draft a charter, but the charter isn't something that has to be settled on my the WG. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Personally, I think each on-the-face-of-it-reasonable suggested improvement has to be considered, but the more time passes and the more the specifications are mature, the higher the bar is raised. Since these specs. have been around a while and have been implemented it seems reasonable to start this WG with a higher bar than one where neither of those things are true. I strongly disagree. Implementation of a draft specification is useful to establish a proof-of-concept and perhaps (especially if there are multiple independent implementations), to unconver potential ambiguities in the draft specification. Implementation is not however a good indicator of protocol soundness. This might have been sufficient in ARPAnet days, but on the scale of today's Internet it is necessary to perform extensive analysis and review - neither of which have been done for DKIM. So no, it's not appropriate to raise the bar for changes on the basis of existing DKIM implementation. At most, the charter should specify that new DKIM signatures be distinguishable from signatures made according to the old DKIM specification. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
1. As interesting as such a discussion might be, it has no effect on the technical work. The choices made were the choices made. The goal is to make as few new ones as we can, not to spent time reviewing past choices. That is almost never an appropriate goal for an IETF working group creating a standard. The goal of a standard-setting working group is to understand and describe what will work well for the Internet as a whole and to vett that design via wide review, not to rubber-stamp what has been designed by a small group of people and deployed under relatively limited circumstances. -I'm suggesting the WG tell the IETF what, if anything, is wrong with the bits the IETF had already done. Earth to Ted: THAT'S NOT THE JOB OF THIS WORKING GROUP. Dave, you are not the one who decides what this working group does. that's IESG's job. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
the specification is way too high for that. Too high for what? Instead of arguing principles Eric, needs to indicate what specific technical work that is excluded by this language is actually essential to the goals of DKIM. Dave, You keep making statements like that without a shred of support for your position. You seem to think that you alone dictate the conditions under which a working group should be chartered. You are mistaken, and IMHO your efforts are hindering progress of the the DKIM effort. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. implies the need to be clarify the charter in two ways. The charter needs to reaffirm that the IETF has change control over the specifications at this point, so that there is no question over who gets to decide whether an incompatible change is necessary. The charter also needs to indicate that the working group will consider the relationship of this work to other, existing IETF technologies. I'll go further than that. The text you quoted from the proposed charter is inappropriate, and needs to be removed entirely. DKIM as currently envisioned has serious flaws that not only limit its flexibility but which will do harm to domains that do not fit its Procrustean model for policy advertisement. The flaws are fixable, and with the fixes DKIM could be quite useful for discouraging forgeries. But the flaws aren't fixable without making incompatible changes. The only when necessary for success clause raises the bar for changes too high. At best it is confusing because different people define success in different ways. There are unfortunately some DKIM proponents who want IETF to rubber stamp this protocol, despite its widely acknowledged flaws. If this clause is allowed to stand they will try to use it as a stick to prevent changes that would make DKIM much more widely applicable. The DKIM working group should have complete latitude to change any feature of the current DKIM protocol. The DKIM protocol is neither widely deployed enough nor useful enough in its current form to dictate features of an IETF standard protocol. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
It's also a principle of good engineering that you don't make unnecessary changes to deployed code. I think that's an overgeneralization. There's neither a wide enough deployment of DKIM, nor sufficient evidence of DKIM's suitability for the diverse user community, for the current DKIM specification to dictate the standard protocol. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
It's a significant precedent that IETF charters have included language of this sort when there has been a deployed base at the time the WG is chartered. But can someone explain what's different in this wording that warrants departing from the version on which there seems to be rough consensus? there isn't a DKIM WG yet, so rough consensus of the mailing list is irrelevant. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Ted Hardie wrote: At 9:07 AM -0500 12/21/05, Tony Hansen wrote: I would be happy with the text that was used in the xmpp charter: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. This text still keeps the bar high for unnecessary changes, was already vetted through an existing charter, and helped us through a similar impasse when xmpp was chartered. Tony Hansen [EMAIL PROTECTED] I agree with Tony on the benefits of re-using this language, and it certainly works for me. Me too FWIW. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Ted Hardie wrote: I would be happy with the text that was used in the xmpp charter: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. I agree with Tony on the benefits of re-using this language, and it certainly works for me. Then it sounds like we have some text that we can compromise on. Jim Fenton has already said that this text covers his concerns about as well as what we had, Stephen Farrell has accepted it, and now I'm weighing in. I suggest that the IESG replace that paragraph in the proposed DKIM charter with the paragraph above, and that we move on from this topic to any others that need to be dealt with. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
Fellow DKIMers, Barry Leiba wrote: I suggest that the IESG replace that paragraph in the proposed DKIM charter with the paragraph above, and that we move on from this topic to any others that need to be dealt with. Well, I guess no one else is concerned about the sequence that has just taken place. We carefully develop charter language through two, complete, multi-month rounds of open collaboration, including significant focus on exactly the language in question, both times. Some folks come in at the late stage of the second open process and seek to change this text, but they fail to develop support. So they re-assert their concerns again during the IETF charter last call, and now the chairs quickly concede the change, even before getting support from the rest of the group. It's not that the proposed language is bad, it is that this sequence bodes rather poorly for dealing with further demands from folks who fail to gain support. And it does not help that two of those doing the (re-)demanding are area directors and another an IAB member, raising the fear that the current concession is strictly to appease the authority those folks have. All this with no specific technical concerns driving the demand. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. I agree with Tony on the benefits of re-using this language, and it certainly works for me. It does not work for me. It is biased in the wrong direction. It is entirely inappropriate to encourage the WG to produce output that is compatible with a specification that is known to have significant flaws. Consider also the following: a) we already know that incompatible changes are necessary, thus verifying software will need to be upgraded b) as DKIM is specifically NOT intended to provide assurances of message authenticity for more than a few days, compatibility with existing signatures is of little consequence anyway I suggest that the IESG replace that paragraph in the proposed DKIM charter with the paragraph above, and that we move on from this topic to any others that need to be dealt with. I suggest the IESG replace the paragraph with the following: While it is understood that the WG will use the current DKIM specifications as a starting point, the WG is neither expected nor constrained to specify a standard which is compatible with those specifications. The WG should feel free to make whatever changes are necessary to produce a specification that is robust with respect to the requirements and flexible enough to support a diverse set of usage scenarios. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
Dave Crocker wrote: and now the chairs quickly concede the change, even before getting support from the rest of the group. 'scuse me; it seemed to me that Tony Hansen and Jim Fenton counted as some of the rest of the group. It also seems to me that no one has made me the boss, so what I suggested was just that: a suggestion. You may feel free to spend more time arguing about that paragraph if you like. My opinion (and that's all it is) is that that's not useful. I understand the principle you're fighting for, Dave. And I think it will come up again, which is why you're fighting it. I think it will be better to fight it later, if necessary. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Tony Hansen wrote: I would be happy with the text that was used in the xmpp charter +1 And http://permalink.gmane.org/gmane.ietf.dkim/1568 is no strong objection, or is it ? Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)
Barry, I understand the principle you're fighting for, Dave. And I think it will come up again, which is why you're fighting it. ack. I think it will be better to fight it later, if necessary. It always seems that way, at the time. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
We have had three proposal for some text on changes to prior work, the current proposed charter, the text from the XMPP charter, and the text Keith provided below. The question that I think IESG should be asking themselves is how is this similar and/or different from other groups the have chartered or will in the future. Nearly every group has some people with a fairly strong idea of at least one way to solve the problem. Without this, it is usually not clear the work is even possible. Now some groups, XMPP for example, perhaps TLS long ago, have substantial deployment with difficult backwards compatibility questions - theses situation might require the charter to provide more than normal limitations to the scope of the solutions that are possible. I'm failing to see that dkim has existing deployments or difficult backwards compatibility problem that would cause the need for some special text in the charter more than you average WG. (They do have difficult backward compatibility problems with existing email systems and I like the text that limits the scope on that.) 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 fail to see the analogy to XMPP but perhaps there is a good reason for something more like XMPP. I'd sure want whoever approved this charter to be able to give me a clear reason why they though this WG would produce better work by having this constraint. It's going to set a precedent for things to come. Practically speaking, I'm not sure it will make much difference to the work that the WG produces. If the individuals that will form the WG feel that the WG has consensus that they will not make changes beyond a a certain boundary, they don't need the charter to set that boundary. The strong arguments that this needs to be in the charter makes me wonder if the individuals that will form the WG will agree to very limited changes or not. If they will, it's barely worth arguing for here. Related to how much the charter pre-supposes the solution, the sentence that Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. seems like a pretty heavy constraint on the possible solutions and one that some proposals disagreed with. I'm not arguing against the current dkim drafts, I am arguing that the future of doing internet drafts should not be a process where we come to agreement in a dark and smokey room with a small group of people then set up WG where effectively only syntax level changes can be made. If we like these drafts as is, let's skip the WG and just take them forward as AD sponsored individual drafts and call it done, if we think we need a WG, allow it to have change control to select a reasonable solution to the problem. On 12/21/05 4:07 PM, Keith Moore moore@cs.utk.edu wrote: I suggest the IESG replace the paragraph with the following: While it is understood that the WG will use the current DKIM specifications as a starting point, the WG is neither expected nor constrained to specify a standard which is compatible with those specifications. The WG should feel free to make whatever changes are necessary to produce a specification that is robust with respect to the requirements and flexible enough to support a diverse set of usage scenarios. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
I believe the text here: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. implies the need to be clarify the charter in two ways. The charter needs to reaffirm that the IETF has change control over the specifications at this point, so that there is no question over who gets to decide whether an incompatible change is necessary. The charter also needs to indicate that the working group will consider the relationship of this work to other, existing IETF technologies. That does not imply that it needs to adopt them, but explaining why it chose to use, for example, this signature mechanism rather than one of the existing ones would help the IETF understand whether this mechanism is a better point solution, implies a problem with the existing mechanisms which should be fixed in the existing solutions, or should be considered as the basis of a more wholesale replacement. Doing so in its first milestone document seems like a reasonable way to accomplish this, but doing so in the standards-track specifications also seems reasonable. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Ted, implies the need to be clarify the charter in two ways. The charter needs to reaffirm that the IETF has change control over the We could choose to have every charter repeat every premise for all IETF work. That would be wasteful, at best. Having this point in this charter mostly serves as a statement of mistrust, rather than providing any useful education or constraint. charter also needs to indicate that the working group will consider the relationship of this work to other, existing IETF technologies. Again, a nicely open-ended and universal requirement that applies to all working groups. It is therefore meaningless, except for its implicit threat at more overhead and undefined requirements to satisfy. That does not imply that it needs to adopt them, but explaining why it chose to use, for example, this signature mechanism rather than one of the existing ones would help the IETF understand whether this If you have specific questions that you believe the wg needs to attend to, then they should have been stated during the very oppe, very lengthy (and repeated) charter development process. Calling for the addition of a requirement that cannot be satisfied in any predictable fashion is entirely counter-productive, Ted. regards, /d -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
At 2:44 PM -0800 12/20/05, Dave Crocker wrote: Ted, implies the need to be clarify the charter in two ways. The charter needs to reaffirm that the IETF has change control over the We could choose to have every charter repeat every premise for all IETF work. That would be wasteful, at best. It's also a principle of good engineering that you don't make unnecessary changes to deployed code. This working group charter sees a necessity to repeat that position in the charter. That's fine by me. I think adding in that it is the working group that decides when that necessity hits is a good idea in that case. That's not mistrust of anyone, it's ensuring that everyone, including those who join *after* this long, repeated charter development process understand how that statement in the charter fits into the rest of our assumptions. Note that very similar language was in the XMPP charter (http://www.ietf.org/html.charters/OLD/xmpp-charter.html), which had a relationship to the deployed jabber code: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. I personally believe that clarity helped the XMPP working group and the jabber community. Having this point in this charter mostly serves as a statement of mistrust, rather than providing any useful education or constraint. charter also needs to indicate that the working group will consider the relationship of this work to other, existing IETF technologies. Again, a nicely open-ended and universal requirement that applies to all working groups. It is therefore meaningless, except for its implicit threat at more overhead and undefined requirements to satisfy. I had hoped the sentences following the one you snipped were clear, but apparently not. As Eric Rescorla has several times pointed out (http://www.educatedguesswork.org/movabletype/archives/2005/07/comments_on_dra.html), the IETF has done work on message signing before, and some of those earlier efforts (like CMS in detached signature mode) look enough like pieces of DKIM that there is question of whether DKIM not using them indicates that they do not work, that this message signing is a better point solution, that this message signing mechanism would be better over all, or none of the above. Again, I'm not suggesting a change in what DKIM wants to do--I'm suggesting the WG tell the IETF what, if anything, is wrong with the bits the IETF had already done. Doesn't fit, here's why would be one answer, and there are several logical places to do it.I think that's pretty actionable, and that it would be a useful, timely contribution to the relevant area of Internet engineering. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Ted, We could choose to have every charter repeat every premise for all IETF work. That would be wasteful, at best. It's also a principle of good engineering that you don't make unnecessary changes to deployed code. But since only *some* IETF working groups begin with work that involves deployed code and since the degree of concern for preserving that investment varies, it *is* appropriate to have a charter make clear what choices are made in such a matter. (and since I have cited this point to you quite a few times, I am not sure why you are raising it yet-again.) At any rate, Ted, since you seek to raise a parallel example to substantiate your proposal, perhaps you could choose one that really is parallel? Note that very similar language was in the XMPP charter (http://www.ietf.org/html.charters/OLD/xmpp-charter.html), which had a relationship to the deployed jabber code: That's nice. Again: Do you have specific activities that you want the working group to coordinate with? If you do, what specific coordinations do you seek? Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. I personally believe that clarity helped the XMPP working group and. the jabber community. Me too. But what does that have to do with your request for generic language calling for generic coordination? and some of those earlier efforts (like CMS in detached signature mode) look enough like pieces of DKIM that there is question of whether DKIM not using them indicates that they do not work, that this message signing is a better point solution, that this message signing mechanism would be better over all, or none of the above. Two reactions: 1. As interesting as such a discussion might be, it has no effect on the technical work. The choices made were the choices made. The goal is to make as few new ones as we can, not to spent time reviewing past choices. If you are calling for considering changing them, then you need to state what kinds of changes you are seeking. For that matter, if you want to re-visit those choices, then you have had something like 5 months to do that. Why must the working group be burdened with this overhead, since it has no utility for turning out a useful spec. 2. Excellent. Clearly you have specific questions you want answered and you want them in the charter. Please state them. And, by the way, I seem to recall that they *were* raised and discussed in the extended and repeated open-discussion of the charter over the 5 months it has taken to get this far. What is it about that extended, prior charter development that you find inadequate? Again, I'm not suggesting a change in what DKIM wants to do Then the draft charter text does not need changing. -I'm suggesting the WG tell the IETF what, if anything, is wrong with the bits the IETF had already done. Earth to Ted: THAT'S NOT THE JOB OF THIS WORKING GROUP. As has been discussed a number of times, the issue is an interesting topic and well worth exploring. But it is not appropriate to task this specification effort with that analysis task. (And by the way, I thought this point was settled during the Vancouver IETF.) d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
At 3:49 PM -0800 12/20/05, Dave Crocker wrote: 1. As interesting as such a discussion might be, it has no effect on the technical work. The choices made were the choices made. It has an effect on the technical work of the IETF, by creating a new mechanism in this space. Describing what it makes it better/different/more appropriate helps those who will interpret or re-use these pieces understand why they might choose to re-use them or avoid doing so. Saying this is a point solution or this is a replacement for $FOO, and here's why we chose to replace it is relevant to the people who will read and use the specifications. It's relevant to the IETF, in other words, as well as a broader community. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. As I argued on the DKIM working group list, I think this text is a bad idea. Part of IETF having change control of a specification is having the ability to make changes, and the bar of necessary to the success of the specification is way too high for that. Note that I'm not suggesting that the WG shouldn't consider compatibility, merely that it shouldn't be effectively prohibited by charter from making incompatible improvements. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Ted. It has an effect on the technical work of the IETF, by creating a new mechanism in this space. 1. Not really. 2. This has been discussed to death, over the last 5 months. Is there something about it that you did not understand? 3. What effect is it going to have on other IETF technical work? Again, Ted, it sure would be helpful for you to cite specifics rather than abstractions, since it is specifics that the IETF delivers. Describing what it makes it better/different/more appropriate helps those who will interpret or re-use these pieces understand why they might choose to re-use them or avoid doing so. Ahh. So you would like every new effort to produce a document that records every detail of a group's decision process? Well, yes, that would certainly be a good disincentive for ever trying to get work done in the IETF. A working group would be assured of spending all of its time trying to satisfy these abstract debates -- and never knowing whether it would succeed -- rather than getting to deliver technical specifications. Oh, that's what we already seem to be, these days. Oh, you don't want it for *all* new efforts, just those doing anything that in any way relates to prior work? Hmmm. Actually, that's most IETF work. Saying this is a point solution or this is a replacement for $FOO, and here's why we chose to replace it is relevant to the The nature and purpose of DKIM is stated in the DKIM spec. It says neither of the things you have stated. So we are now wandering around in territory that appears to have nothing to do with DKIM. people who will read and use the specifications. It's relevant to the IETF, in other words, as well as a broader community. It's probably more relevant to the IETF community to show that we can get useful work done in a timely manner. Your re-raising old topics and arguing for conceptual discussion seems rather counter-productive to that end. regards, d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
At 2:44 PM -0800 12/20/05, Dave Crocker wrote: The charter needs to reaffirm that the IETF has change control over the Having this point in this charter mostly serves as a statement of mistrust, rather than providing any useful education or constraint. Fully disagree. There is plenty of recent evidence that WGs that are formed around charged issues attract lots of active interest from people who do not understand the IETF rules. We certainly saw this in the Atompub WG, and it seems likely that you will see it in any WG relating to spam. Adding this type of wording to charters of WGs which come with existing protocols helps set the expectations of the participants and therefore could help the WG act more gracefully. Adding such a statement is all about education. It is perfectly reasonable to not trust that newcomers will understand IETF policy; heck, many folks who have been active for years don't. charter also needs to indicate that the working group will consider the relationship of this work to other, existing IETF technologies. Again, a nicely open-ended and universal requirement that applies to all working groups. It is therefore meaningless, except for its implicit threat at more overhead and undefined requirements to satisfy. The same reasoning above applies here. Having people whose sole involvement with the IETF is one new WG know that there is an expectation that some research will be done will hopefully reduce tensions during IETF Last Call and IESG review when questions like why didn't you use this standards-track technology instead of inventing your own, or why did you pick this standards-track technology over that standards-track technology, are asked. Having these things in the charter reduces the strain on the chairs when the issues come up in the WG. At 5:04 PM -0800 12/20/05, Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. As I argued on the DKIM working group list, I think this text is a bad idea. Part of IETF having change control of a specification is having the ability to make changes, and the bar of necessary to the success of the specification is way too high for that. Note that I'm not suggesting that the WG shouldn't consider compatibility, merely that it shouldn't be effectively prohibited by charter from making incompatible improvements. It is fortunate that the Atompub WG didn't have language like this in our charter, because we made many improvements from the widely-deployed, pre-IETF Atom 0.3 spec. Having such language would have made it harder to get them in the final spec, and therefore would have degraded the quality of the WG's output. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Having this point in this charter mostly serves as a statement of mistrust, rather than providing any useful education or constraint. Fully disagree. There is plenty of recent evidence that WGs that are formed around charged issues attract lots of active interest from people who do not understand the IETF rules. Adding such a statement is all about education. It is perfectly reasonable to not trust that newcomers will understand IETF policy; heck, many folks who have been active for years don't. 1. You said you disagreed, but then provided an argument for not trusting participants (people who do not understand the IETF rules.) 2. You cannot seriously think that adding the language Ted suggests -- he *did* suggest specific language, didn't he? I've lost track -- will make any difference to the working group process. 3. Adding such language is not a remedy for bad working group management or participation, yet that is exactly what Ted and you seem to be targeting. Since it does not target technical details of the work to be specified -- remember you said education -- that means that we now need to make charters bullet-proofed against an essentially infinite range of misunderstandings, as well as presuming that participants are not to be held responsible for reading basic IETF materials. But then why should they be held responsible for charter contents? Again, a nicely open-ended and universal requirement that applies to all working groups. It is therefore meaningless, except for its implicit threat at more overhead and undefined requirements to satisfy. The same reasoning above applies here. Having people whose sole involvement with the IETF is one new WG know that there is an You are attempting to impose a new requirement for a charter, namely that it be bullet-proofed against ignorant participants. That sounds like an interesting item to pursue in the IETF process enhancement discussions, because the expectation of such content in a charter is not specified in any current IETF process documents. expectation that some research will be done will hopefully reduce tensions during IETF Last Call and IESG review when questions like why didn't you use this standards-track technology instead of inventing your 1. The question has been discussed and explained at length on the mailing list, the two BOFs, and elsewhere, for the last year. 2. You are presuming that it is reasonable for someone to come in at the end of a working group and require a defense of the initial position of the work. Since such a question belongs at the beginning of the process -- assuming that anyone has noticed that this work continues existing work rather than creates new work -- it is not productive to have such basic challenges lodged at the end of the process. Having these things in the charter reduces the strain on the chairs when the issues come up in the WG. What wording changes, specifically do you believe will 'reduce the strain on the chairs' for this particular working group? Please provide examples of similar language having had similar benefit. Again note that you seem to be arguing for charter language that does not target specific technical work but, instead, seems to have some other goal relating to difficult participants. (This is as opposed to language that targets technical work in a way that constrains such difficult people.) Remember that Ted has already acknowledged that he is not seeking any change in the actual technical work of the group. He is, therefore, merely seeking to burden the wording group with an additional task that has nothing to do with the direct work at hand. At 5:04 PM -0800 12/20/05, Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. As I argued on the DKIM working group list, I think this text is a bad idea. Part of IETF having change control of a specification is having the ability to make changes, and the bar of necessary to the success of And Eric seem to keep ignoring, the question of how much change to target, when taking in existing technology, is an established point that has been experienced a number of times already. Different choices have been made. Those seeking to field DKIM have reached a consensus on charter language that reflect their choice for this case. (In other words, Eric, rough consensus has been established on this issue.) The impression, at this point, is that those seeking to remove all limits on the technical changes in fact have no interest in protecting the existing work. In that light, the folks who developed DKIM would be quite seriously crazy to hand it over to the IETF. the specification is
Re: WG Review: Domain Keys Identified Mail (dkim)
Dave == Dave Crocker [EMAIL PROTECTED] writes: Dave If you have specific questions that you believe the wg needs Dave to attend to, then they should have been stated during the Dave very oppe, very lengthy (and repeated) charter development Dave process. Dave, there are two ways of reading this and if people read it incorrectly they might come across with the impression that you were attempting to short circuit community review. The first way of reading this is that it would be very nice if people with specific concerns brought them up in the charter discussion. That's certainly true. We don't want this WG review to be drawn out and we want to move forward with WG creation. I agree strongly with that reading. The second is that by failing to do so, people have given up their ability to bring forward these concerns or would not be constructive by doing so. While it is possible to be non-constructive at any stage of the process, this is the first time that DKIM has formally been before the community for review. We had a BOF, but that was not attended by the entire community; this WG review is the formal point in our process where the community can bring up concerns with the charter. At this stage, it is appropriate to bring up concerns or to reiterate that a concern previously brought forward has not been addressed. In the latter case, we solicit input from the community about whether the concern needs to be addressed. I realize you know all this. I've been a bit more verbose than is strictly necessary in the hopes of letting everyone know that we do value their constructive input but we do require they keep that input constructive. Thanks, --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Dave Crocker [EMAIL PROTECTED] wrote: At 5:04 PM -0800 12/20/05, Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. As I argued on the DKIM working group list, I think this text is a bad idea. Part of IETF having change control of a specification is having the ability to make changes, and the bar of necessary to the success of And Eric seem to keep ignoring, the question of how much change to target, when taking in existing technology, is an established point that has been experienced a number of times already. Different choices have been made. Those seeking to field DKIM have reached a consensus on charter language that reflect their choice for this case. (In other words, Eric, rough consensus has been established on this issue.) Rough consensus inside some subgroup, not inside IETF. Indeed, that's precisely the question that a Last Call is designed to answer. The impression, at this point, is that those seeking to remove all limits on the technical changes in fact have no interest in protecting the existing work. That may be your impression, but that doesn't mean it's the case. In that light, the folks who developed DKIM would be quite seriously crazy to hand it over to the IETF. I agree that if they aren't willing to cede change control to IETF then they shouldn't hand it over, yes. the specification is way too high for that. Too high for what? Instead of arguing principles Eric, needs to indicate what specific technical work that is excluded by this language is actually essential to the goals of DKIM. Yes, you've asserted this repeatedly. And I've repeatedly disagreed. I don't see much point in us going over that ground again. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Domain Keys Identified Mail (dkim)
Sam, Dave If you have specific questions that you believe the wg needs Dave to attend to, then they should have been stated during the Dave very oppe, very lengthy (and repeated) charter development Dave process. Dave, there are two ways of reading this and if people read it incorrectly they might come across with the impression that you were attempting to short circuit community review. I can't imagine how my noting that there have been two, extended rounds of open discussion and revision -- including two IETF BOFs -- could be taken as an attempting to short-circuit community review. What I CAN imagine is that pursuing such a point will take us all that much farther away from chartering this group. Please remember that this is a group that has been jumping through IETF start-up hoops for 5 months already. (By the way, I lied. I can imagine all sorts of ways people can choose to misinterpret someone's statements, no matter what the person has actually said.) The first way of reading this is that it would be very nice if people with specific concerns brought them up in the charter discussion. That's certainly true. We don't want this WG review to be drawn out and we want to move forward with WG creation. I agree strongly with that reading. Me too. The second is that by failing to do so, people have given up their ability to bring forward these concerns or would not be constructive by doing so. But Sam, that is ultimately the way the IETF does get work done: People who do not participate during an extended, open and productive process must not be allowed to come in afterwards and insist things be done differently. (Please note that I already acknowledged that it won't work is always relevant, but that's not what we are dealing with here.) While it is possible to be non-constructive at any stage of the process, this is the first time that DKIM has formally been before the community for review. No, Sam. That is not correct. DKIM has been before the IETF community for 5 months. This is a last call event, not a first call. It is a chartering last call. And let me anticipate those who view it differently: If the IETF has any hope of being productive in the long term, it needs to find a way to stop re-visiting territory that has already been worked. What we have now is a process that requires constantly re-arguing topics. There is really no way to make anything that looks like timely progress, if even one person feels like arguing against it at any point in the process. We had a BOF, but that was not attended by the entire community; this WG review is the formal point in our process where the community can bring up concerns with the charter. 1. That's not the issue here, since Ted has participated in earlier discussions. He didn't like the rough consensus that was reached, so he's raising his concerns yet-again. 2. The concerns raised here, so far, have nothing to do with the technical or functional adequacy of the proposed work. 3. Perhaps you have heard a real concern expressed. I've missed it, but would love to hear someone else characterize it. So far, the view seems to be that we are expected to a) entirely ignore and repeat previous work, and/or b) all the work of educating people who are not willing to review the public discussion archive -- particularly irksome when they themselves contributed to it, and/or c) enter into a standards process that insists on complete instability for those who have already invested 1-2 years creating the technology and services on which this effort is to be based. And, yes, I believe that the situation is exactly that extreme, which is why I am taking such a harsh tone. When someone bothers to do their homework and to raise a new question about the actual technical work, or its utility, that has not already received extended discussion, then they will not be wasting everyone's time. (Variant: I don't know if this has been discussed before, but what about...? presumably is a question that will be satisfied by pointing to the relevant place in the online archive.) At this stage, it is appropriate to bring up concerns or to reiterate that a concern previously brought forward has not been addressed. Except that Ted's concerns HAVE been addressed, Sam. I realize you know all this. I've been a bit more verbose than is strictly necessary in the hopes of letting everyone know that we do value their constructive input but we do require they keep that input constructive. Sam, from what I've seen, you are pretty consistent about trying to find a productive path. I often do not agree with your assessment of what that path should be, but that's ok, because it seems pretty clear that you actually care about finding answers (or at least compromises) rather than just lobbying for your pet preferences. In the IETF, that kind of participation is
Re: WG Review: Domain Keys Identified Mail (dkim)
The IESG wrote (quoting the proposed DKIM charter): Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of the specifications. Ted Hardie wrote (quoting an XMPP charter): Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. I don't really see much difference between the two sentences. In one case, the bar is necessary for the success of the specifications while in the other case it's required to meet the group's technical objectives (and hopefully the group's technical objectives are for the success of the specifications). In one case, non-backwards-compatible changes are not encouraged, while in the other, every reasonable attempt is made to keep things compatible. It's a significant precedent that IETF charters have included language of this sort when there has been a deployed base at the time the WG is chartered. But can someone explain what's different in this wording that warrants departing from the version on which there seems to be rough consensus? -Jim ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
