Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On Saturday, April 02, 2011 02:49:49 PM Michael Thomas wrote: > Dave CROCKER wrote: > > The distinction that needs to be made is between formally-specified > > output vs. implementation-specific access to DKIM internals. > > i= was never intended to be "DKIM internals". That's why the entire gambit > to make d= the only show in town sucked. +1. I don't particularly agree with the idea that the work of the working group is 'done', but it does seem that we'd be better off if we stopped 'improving' things sooner rather than later. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
Dave CROCKER wrote: > The distinction that needs to be made is between formally-specified output > vs. > implementation-specific access to DKIM internals. > i= was never intended to be "DKIM internals". That's why the entire gambit to make d= the only show in town sucked. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
On 4/1/2011 11:04 PM, Murray S. Kucherawy wrote: > My recollection was that we decided DKIM has to produce at least one specific > output, and that the spec needed to identify what that one particular item > was. We never precluded it from making other information available. Just to be very clear about the actual terms of the specification: From RFC 5672 >This Update defines the output of that library to include the yes/no >result of the verification and the "d=" value. In other words, it >says what (one) identifier was formally specified for use by the >signer and whether the use of that identifier has been validated. >For a particular library, other information can be provided at the >discretion of the library developer, since developers of assessors -- >these are the consumers of the DKIM library -- well might want more >information than the standardized two pieces of information. >However, that standardized set is the minimum that is required to be >provided to a consuming module, in order to be able to claim that the >library is DKIM compliant. The language "at least one" does not quite match the actual semantics, since it means that the "output" of DKIM can be variable. The distinction that needs to be made is between formally-specified output vs. implementation-specific access to DKIM internals. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
> Moreover, it's substantially more than the percentage that appear to be > using "x=", but we're not considering removing that here. I suspect I'm not the only person who'd be thilled if we got rid of x=, since it's yet another unverifiable assertion, but I figure we're draining one swamp at a time. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
On 02/Apr/11 09:08, Hector Santos wrote: > I would suggest an aura is present that the "job is not done" > especially when there are still active discussions about removing, > deprecating, changing this and that, and there is still a chartered > POLICY standard development work item yet not complete. ...and EAI coming up. I agree that the presence of such aura is not a sufficient reason for keeping the WG, and more so if we keep in mind other considerations. At any rate, do we agree that such aura is present or is it just a minority of us who feel it? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Open issues in RFC4871bis
Murray S. Kucherawy wrote: > The text in question is this: > > 2.3. Identity > >A person, role, or organization. In the context of DKIM, examples >include the author, the author's organization, an ISP along the >handling path, an independent trust assessment service, and a mailing >list operator. Sorry, but for the record I can't help to feel there is something wrong, a sense of conflict of interest, with this inclusion of "independent trust assessment service." We could be also fair and independent with foresight for additional future DKIM assessment models and future business markets and this in as well: "Centralized Repository Domain POLICY Service Bureaus" which may not be based on d= only. When your definition includes other entities such as the author, you need to also thru in POLICY if you are going to include this "independent trust assessment service." To be on par with the mail system form of the other identities you have, it seems to ne "signer domain" would be enough, we get it. If you really bent on this, maybe using [independent] signer assessment source|agent would smell better. -1 to have this wording you proposed. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of John R. Levine > Sent: Friday, April 01, 2011 2:40 PM > To: Rolf E. Sonneveld > Cc: DKIM List > Subject: Re: [ietf-dkim] Work group future > > > By closing down the WG the momentum will be lost; > > There's plenty of momementum in MAAWG and other operational fora. The > IETF is about standards development. You don't get deployment by keeping > a standards WG going. +1. MAAWG has been the incubator for a lot of ideas and energy that fed into standards work, most notably ARF but also some aspects of DKIM, SPF and Sender ID. It has a broad membership base (http://www.maawg.org/about/roster) so their constituency in terms of gathering deployment experience and input is substantial and ideal for this sort of work. And there are lots of smaller efforts starting to pop up that are putting forward ideas in this area as well. There's no lack of momentum. In terms of chartered items, we've done 1 and 5 insofar as we have documents getting ready to go to the IESG, but we've been spinning our wheels on the rest for a long time now. WGs are expensive to spin up and operate, and if we're not getting anywhere then it's appropriate to go dormant or shut down completely. A new working group can spin up to tackle those issues someday when there's real progress to be made. And I think that's a better use of everyone's time. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
Murray S. Kucherawy wrote: > [as regular participant, not document editor] > > Moreover, it's substantially more than the percentage that > appear to be using "x=", but we're not considering removing > that here. > > So it seems like we've got this theory that simpler > is better, but we're applying that theory piecemeal. > It may not be your intent, but lets not indirectly instill the idea x= should be a considered candidate for removal. This DKIM feature has an easy understanding, feel and grasp for utility. It is easy to explain to producers and consumers, easy to employ and simply something people can actually use if so desired. i= is a much different issue. For its functionality, I can't speak I had a full understanding for its use cases other than an intent for user level signings. I also never understood why it remained over the years when it seemed to be something yet fine tuned and there was still the long time concerns of its DNS scalability. Yet, it hung around but seem to become one of the DKIM features that would not be used much. From the software angle, when the key record g= tag is no longer part of the spec, then i= is less software wise required. Can't speak for OpenDKIM, but in the ALT-N (verifier) API, any i= value defined in the signature is only applied when a key record g= tag value is defined. From the testing standpoint, I found a need to modified the API to add an verifier CheckGranularity=1|0 option because we found false positives with computational valid signatures but an failed NO SIGNATURE result due to a failed g=/i= granularity wildcard string comparison checks. The check option was provided with a noted concern it might promote a security loophole if disabled. From a documentation standpoint (F1 online help, etc) in describing the what, why and when to use reasons for his particular i= option, was not easy to do especially when it came to the DNS management aspects. -- Hector Santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
John R. Levine wrote: >> By closing down the WG the momentum will be lost; > > There's plenty of momementum in MAAWG and other operational fora. The > IETF is about standards development. You don't get deployment by keeping > a standards WG going. Not suggesting to keep the bar open for after hours drinks and ramblings whispers, but MAAWG represents a itsy-bitsy fragment of the total mail network population interest. Its not the IETF and I would suggest an aura is present that the "job is not done" especially when there are still active discussions about removing, deprecating, changing this and that, and there is still a chartered POLICY standard development work item yet not complete. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Open issues in RFC4871bis
> -Original Message- > From: John Levine [mailto:jo...@iecc.com] > Sent: Friday, April 01, 2011 9:10 PM > To: ietf-dkim@mipassoc.org > Cc: Murray S. Kucherawy > Subject: Re: [ietf-dkim] Open issues in RFC4871bis > > >2.3. Identity > > > > A person, role, or organization. In the context of DKIM, examples > > include the author, the author's organization, an ISP along the > > handling path, an independent trust assessment service, and a mailing > > list operator. > > The current language looks fine to me. [as participant, not document editor] +1. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Jim Fenton > Sent: Thursday, March 31, 2011 2:34 PM > To: IETF DKIM WG > Subject: [ietf-dkim] Proposal: Removal of AUID (i= tag/value) > > The direction of the DKIM specifications since RFC 4871 have been to > rely less and less on the AUID (agent or user identifier, the i= value > on the signature) to the point that it provides no security benefit. On > the other hand, a malformed AUID can cause a DKIM signature not to > verify, and i= currently adds to the complexity of the DKIM > specification. For this reason, I am formally proposing that the i= tag > and supporting text be removed from 4871bis. > [...] [as regular participant, not document editor] I find myself undecided, and I need to think about it a little more. I certainly agree that simplifying the specification by removing stuff that provides little use is a good idea, and we've done so with "g=" as well and I'm fine with that. OpenDKIM's statistics show that almost half of signatures use "i=", in contrast to how few used "g=" in other than the default way. Of those that do, only about 35% are using it in other than the default way. So that's at least 17% of signatures overall that are trying to do something with "i=". That's non-trivial. Moreover, it's substantially more than the percentage that appear to be using "x=", but we're not considering removing that here. So it seems like we've got this theory that simpler is better, but we're applying that theory piecemeal. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
