Re: [ietf-dkim] Output summary
At 19:33 29-04-2011, Murray S. Kucherawy wrote: I quite agree that there's lots of text that's changing, but I'm having trouble finding much in the way of actual protocol change. Most of the changes I can recall have to do with dropping advice or technical context that was simply incorrect or poorly stated given the hindsight we now have. Fixing all of that can only help future implementations. That sounds fine as long as there is agreement on the new text. This is why moving to DS is not allowed if we add stuff, only if we remove stuff. So far, unless I've missed something, that's all we've done. DS is not about not adding stuff and removing stuff. The advancement is about the maturity of the specification. This can be gauged in terms of implementation and interoperability. There are different approaches for such a move; a conservative one where changes are narrow to avoid destabilizing the specification or one where the rationale is changed without affecting the requirements. This case can be argued both ways. I prefer to see implementer buy-in than a label in name only. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary
Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Current implementations are irrelevant. They will completely and utterly ignore what is in 4871bis, because they are done and work fine. The problem is whether we've introduced problems which will cause new implementations to not interoperate with current implementations. Given the huge number of changes, it's impossible to tell without getting real life data. I quite agree that there's lots of text that's changing, but I'm having trouble finding much in the way of actual protocol change. Most of the changes I can recall have to do with dropping advice or technical context that was simply incorrect or poorly stated given the hindsight we now have. Fixing all of that can only help future implementations. Probably, but with less functionality which will not depict the current DKIM Service Architecture currently supported by implementations. This is why moving to DS is not allowed if we add stuff, only if we remove stuff. So far, unless I've missed something, that's all we've done. But I think the comments are suggesting there really isn't anything new being added from what is not already peppered throughout the document in some form providing non-spec changing justification to include in-scope outputs in the proposed Output Summary. Isn't RFC4871bis should be about codify existing implementations which if you think about it, what the RFC5585 overview has done? Overall, I believe there are four output values that are not new and can be extracted from DKIM: status d= i= From: You can probably write text for From: Since the From: is a mandatory input header bound to the signature, the address or the domain part of the address may be considered output to be consumed by an optional signature signing practice as described in the DKIM Service Architecture [RFC5585]. It would not be untrue and consistent with RFC5585 which is not new. If we allowed to RFC5451 to RFC4871bis, then we should allow a add a more directly DKIM related reference to DKIM Service Architecture [RFC5585] document. Doesn't that fit with DS? -- 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] Output summary
Current implementations are irrelevant. They will completely and utterly ignore what is in 4871bis, because they are done and work fine. The problem is whether we've introduced problems which will cause new implementations to not interoperate with current implementations. Given the huge number of changes, it's impossible to tell without getting real life data. I quite agree that there's lots of text that's changing, but I'm having trouble finding much in the way of actual protocol change. An assertion that there have been problematic changes, such as going violating the requirements for advancing to Draft, needs affirmative, specific support. Too many changes is generic and unresolvable and therefore cannot be evaluated and is unfixable. What is too many? Where is the IETF basis for claiming that that criterion prevents advancement? What specific changes are problematic? These are the sorts of questions that a generic criticism should engender. Reviewing changes does take a bit of work. In the IETF, folks making complaints are expected to do the work of making things specific. Fortunately, it's relatively easy work. Time-consuming, perhaps, but not cognitively challenging: Just look at the diffs across the draft versions. Diffs are now provided automatically by the IETF's datatracker. No single diff is that massive. The one diff the datatracker does not provide is between the original RFC and the first Internet-Draft, so I've created one, albeit between the RFC and the /second/ version of the draft. The references are conveniently accessible at: http://dkim.org/ietf-dkim.htm#rfc4871bis 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] ISSUE: Updating Section 6.5: Recommended Signature Content
Recommend adding the following paragraph (excuse the XML markup): t There are tradeoffs in the decision of what constitutes the core of the message, which for some fields is a subjective concept. Including fields such as Message-ID for example is useful if one considers a mechanism for being able to distinguish separate instances of the same message to be core content. Similarly, In-Reply-To and References might be desirable to include if one considers message threading to be a core part of the message. /t I like this. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary
Dave, My perspective was that the damage was done per se in the last errata and changes with this bis are irrelevant and don't reflect current existing implementations. Code changes are not necessary for current implementations because they already follow the DKIM Service Architecture with does include ADSP support. However from a strict RFC4871bis and the proposed Output Summary standpoint, it does not reflect with complete DKIM Service Architecture (RFC5585), as it was written, so it be told. Its really a simple matter from my engineering perspective and if I was confusing the DKIM requirement with ADSP requirements, I am not the only one. There is a clear history of this in the WG and I don't see anything reducing the confusion or as I prefer to call it, inconsistencies. One simple Bug Fix: Add Author Identity to the Output Summary with a reference to Checking Signing Practices per RFC5585. Thanks -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Dave CROCKER wrote: Current implementations are irrelevant. They will completely and utterly ignore what is in 4871bis, because they are done and work fine. The problem is whether we've introduced problems which will cause new implementations to not interoperate with current implementations. Given the huge number of changes, it's impossible to tell without getting real life data. I quite agree that there's lots of text that's changing, but I'm having trouble finding much in the way of actual protocol change. An assertion that there have been problematic changes, such as going violating the requirements for advancing to Draft, needs affirmative, specific support. Too many changes is generic and unresolvable and therefore cannot be evaluated and is unfixable. What is too many? Where is the IETF basis for claiming that that criterion prevents advancement? What specific changes are problematic? These are the sorts of questions that a generic criticism should engender. Reviewing changes does take a bit of work. In the IETF, folks making complaints are expected to do the work of making things specific. Fortunately, it's relatively easy work. Time-consuming, perhaps, but not cognitively challenging: Just look at the diffs across the draft versions. Diffs are now provided automatically by the IETF's datatracker. No single diff is that massive. The one diff the datatracker does not provide is between the original RFC and the first Internet-Draft, so I've created one, albeit between the RFC and the /second/ version of the draft. The references are conveniently accessible at: http://dkim.org/ietf-dkim.htm#rfc4871bis d/ -- 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] Output summary
I think this message by Barry in March 2009 summarizing a conference call between Pasi, Stephen and Barry nicely captures the upper/lower layers, ADSP, i= and outputs conflicts that continue today: http://mipassoc.org/pipermail/ietf-dkim/2009q1/011314.html Perhaps Dave to lower confusion, you need to remove the Checking Signing Practices process module from the DKIM Service Architecture or perhaps consider changing the title: DKIM Service Architecture with optional ADSP support Extended DKIM Service Architecture To ADSP or not ADSP, that is the question. -- Sincerely Hector Santos http://www.santronics.com Hector Santos wrote: Dave, My perspective was that the damage was done per se in the last errata and changes with this bis are irrelevant and don't reflect current existing implementations. Code changes are not necessary for current implementations because they already follow the DKIM Service Architecture with does include ADSP support. However from a strict RFC4871bis and the proposed Output Summary standpoint, it does not reflect with complete DKIM Service Architecture (RFC5585), as it was written, so it be told. Its really a simple matter from my engineering perspective and if I was confusing the DKIM requirement with ADSP requirements, I am not the only one. There is a clear history of this in the WG and I don't see anything reducing the confusion or as I prefer to call it, inconsistencies. One simple Bug Fix: Add Author Identity to the Output Summary with a reference to Checking Signing Practices per RFC5585. Thanks -- 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] Output summary - Purported Author
-Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Saturday, April 30, 2011 4:58 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - Purported Author Referencing RFC5451 as an example doesn't promote any current implementation code changes. Correct. That is what I found when the API only provided the three outputs (status, signer, selector). A-R reporting with more relevant information about the process (Checking Signing Practices) did necessitate an extension of the API verification output. That's probably true, but that is also completely different from necessitating a change to the mandatory output. Providing a reference to RFC5585 may not be a bad idea though, and RFC4686 and RFC5863 as well. Perhaps somewhere in Section 1? Section 1 as in Introduction? or Note to the Editor? The editor note, quite obviously, is temporary. For an introduction, I think that will work. Most people perusing a document like quick references to overviews with pictures very helpful. How will you state it? How about: 1. Introduction [...] 1.1. DKIM Architecture Documents Readers are advised to be familiar with the material in [RFC4686] and [RFC5585] and [RFC5863], which respectively provide the background for the development of DKIM, an overview of the service, and deployment and operations guidance and advice. 1.2. Signing Identity [...] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket 23 -- l= and Content-type
What's your counter-proposal to Alessandro's proposal to modify 9.1.1? Oh, that. Replace all of sec 9.1 with: As noted in Section 4.4.5, use of the l= tag enables a variety of attacks in which added content can partially or completely changes the recipient's view of the message. I don't think we actually understand all the ways that l= allows you to shoot yourself in the foot, so I would prefer not to give the impression that if people avoid a few cases we describe, they're safe. 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] Output summary - proposing ODID Originating Domain Identity
On 4/30/2011 9:10 PM, Hector Santos wrote: So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. Oh heck, let's just declare that the DKIM Signing module MAY output anything it wants. That way we satisfy every possible output desire that has been expressed or might be expressed. After all, it's clear that implementers need the permission. Or we might notice that the purpose of a protocol specification is to define conventions that are followed by both sides of an interaction and that specific specifications are constrained to specific functions, in order to keep them tractable. Telling implementers that they are free to follow any local conventions they want violates both of these otherwise-normal requirements. So rather than continue to fight old, settled issues that primarily have to do with making DKIM try to be something it isn', a better idea would be to review: Section 2.1: INFORMATIVE RATIONALE: The signing identity specified by a DKIM signature is not required to match an address in any particular header field ... Section 4.5, i=: INFORMATIVE DISCUSSION: This specification does not require the value of the i= tag to match the identity in any message header fields. Section 4.10: INFORMATIVE DISCUSSION: This document does not require the value of the SDID or AUID to match an identifier in any other message header field. In other words, DKIM has nothing to do with the rfc5321.From field, and therefore it is entirely inappropriate -- that is, out of scope -- for the specification to suggest dealing with it. At least, please show working group rough consensus support for doing what you suggest. 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] Output summary - proposing ODID Originating Domain Identity
-Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Saturday, April 30, 2011 9:10 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity But what it did most of for me (yesterday) was highlight the confusion with AUID with the lack of an official DKIM label for an Originating Domain Identity. I guess I was moving forward the past year with integrating DKIM into our mail products and I see now I was mistakenly labeling the AUID as the FROM domain when its not officially defined as the From domain. That's unfortunate, but it's also the first case I've heard of someone mistaking the AUID for the From: field. So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. We already have a name for that: RFC5322.From. We don't need a new name for something old. I don't see any ambiguity here that needs fixing, unless there are lots of people that want to come forward now and admit they had the same misunderstanding you did. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
