Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
Jim, I found that I got seriously bogged down on some parts of your note, as you and everyone else will surely see. I am glad to try to set up a phone call to get a better channel for discussing this. Beyond the obvious timezone challenges, this week, I've got quite a bit of flexibility in time and am glad to find a slot where I can call you. Also, everyone else is hereby invited to jump in and straighten me out. That said, here's where I got in responding: On 3/28/2011 11:27 PM, Jim Fenton wrote: 1. authors and their organizations could be misinterpreted to mean that the conjunction defines a single identity. But the current text says ...examples include the author, ... so that misinterpretation exists there as well. I'd be fine with just authors' organizations. How is the examples list a misinterpretation? The list was crafted carefully to draw some distinctions that can be significant. Your wording loses the distinction between author and author's organization. I think the distinction is worth maintaining. Just to be clear: A domain name is capable of being author-specific. I recognize that it's not typical, but the construct of 'author' is so fundamental in this game, it's worth acknowledging that it is (still) permitted. 3. One form of assessment service -- of which the late Goodmail was an example -- can give a priori assessment and then indicate tghe assessment by providing the signature to the message before it is sent. That is, the authoring organization passes the message to the assessment service and the assessment service hands back the signature to be included in the message. (The details can vary, of course, but this describes the basic model.) Hence the signature is somewhat akin to a capability token. [I thought I had explained this processing option a number of times over the years, specifically citing the Goodmail example.] That's a specific example of an ISP along the handling path. Goodmail was not an ISP and it was not along the path. . Goodmail .. . . V V Client - Mail - Transfer - Service - Receiver - Recipient Goodmail interacted with the creator of the document and, separately, with the receiving mail service, as an adjunct back office service. To repeat: /It was not in the direct handling path./ DKIM supports that mode of operation quite nicely and it is a particularly powerful operational mode, so it is worth keeping that configuration in mind explicitly. Given how persistent this confusion seems to be it might even be worth more language, though I'm not coming up with a suggestion, offhand. The potential for misinterpretation of this is greater than the benefit of explaining this potential usage scenario, especially since assessment has a very specific definition in the DKIM context. I think we've just seen a good example that indeed it is easily misunderstood. That begs explicit reference, not potentially confusing conflation. Section 2.9, Common ABNF tokens: Two new tokens are defined based on field-name and dkim-quoted-printable. But where are field-name and dkim-quoted-printable defined? field-name is defined in Section 2.10 DKIM-Quoted-Printable is defined in Section 2.11 Would it be beneficial to rearrange the sections to avoid the forward reference? Sounds like moving the current 2.9 to be after the current 2.11 will solve your concern. 6.3 paragraph 5 has changed signing identity to SDID. The signing identity really corresponds to the AUID. That has not been correct for any version of rfc4871bis. The term Signing Identity has no normative value and is now only used in the introductory text. Also note that the Update removed any meaningful semantics for AUID: The AUID comprises a domain name and an optional Local-part. The domain name is the same as that used for the SDID or is a sub-domain of it. For DKIM processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. In fact, the AUID is not part of DKIM's formal output. So the formal specification cannot then direct it be supplied to the assessment engine. Nevertheless, suppose a message with From address j...@marketing.example.com was properly signed with i=marketing.example.com and d=example.com. What the Your example has d= using a 'parent' domain, not a sub-domain. Your following discussion refers to aspects of the spec that concern sub-domains and I am not understanding how the example is relevant to it. Yes, I see that i= has a subdomain but, again, I don't see how that relates to your comments. With obvious trepidation, I am going to raise a concern: On reviewing the text, I find, under the Section 3.5 text for i= includes: The Signer MAY choose to use the same namespace for
Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-04
On 3/28/2011 11:27 PM, Jim Fenton wrote: 1. authors and their organizations could be misinterpreted ... I'm with Dave. It looks clear ro me that it's a list of examples. The Signer MAY choose to use the same namespace for its AUIDs as its users' email addresses or MAY choose other means of representing its users. However, the signer SHOULD use the same AUID for each message intended to be evaluated as being within the same sphere of responsibility, if it wishes to offer receivers the option of using the AUID as a stable identifier that is finer grained than the SDID. I suggest that the first sentence change MAY to might in order to make it non-normative. I further suggest removing the second sentence However It is giving (normative) usage guidance for something that it has already made out of scope. I'd also take out the INFORMATIVE NOTE. It's an opaque token, so a signer can do anything with the mailbox part of that token that it wants. With a d=example.com, you could equally well use i=b...@example.com or i=@bob.example.com. They're different names, but receivers can infer equally little from each of them. The closest I can come to what you describe in Section 6.3 is: If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader. Good lord, no. My users don't see SDIDs or any other part of a DKIM signature. That goes in the same bit bucket with the advice to display the signed and unsigned parts of the message in different colors. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Work group future
Barry Leiba wrote: -- 4. Discussion of the future of the working group Two charter items not yet done: 3. Collect data on the deployment, interoperability, and effectiveness of the Author Domain Signing Practices protocol (RFC 5617), and determine if/when it's ready to advance on the standards track. Update it at Proposed Standard, advance it to Draft Standard, deprecate it, or determine another disposition, as appropriate. 4. Taking into account the data collected in (2) and (3), update the overview and deployment/operations documents. These are considered living documents, and should be updated periodically, as we have more real-world experience. - Is there energy and desire to do this? Not for these two items. Barry, the issue is never about convincing POLICY advocates. This collect data was perceived as yet another way to further put off completing a chartered work product. If we had a true champion as the editor of ADSP, no question, it would of been a lively active working document and WG discussion with sincere updated proposal design changes because of all the high interest and input provided to try to make POLICY work. POLICY was not provided an equal opportunity chance to be a) worked on, b) by a highly motivated believer of his work, and c) was there simply no interest by the editor to do anything about it to move it forward short of just saying it broken, by design, therefore Don't use it, 3rd party signers can ignore it and tried to get it removed from the charter. It never had a chance. We know what POLICY can offer immediate domain security. We spent many man-hours on it with two document products, RFC for SSP Requirements and RFC for Threat Analysis which were essentially ignored. I'm sure any SMTP vendors in the mail business really don't need additional proof of concept to see a how new method effectively legalizing a new higher bar expectation for mail transactions which can help provide a new legal dissemination for legacy operations to a very high zero false positive degree - with no questions asked. So what is the real question we wish answered with Collect Data? Who uses ADSP? Thats easy, systems who support it and all existing APIs support it. The problem is the ADSP editor has promoted the idea ADSP is broken and promotes the idea that 3rd party signers (like mailing list) do not need to support it. So within the WG, there will be little incentive to support an idea not even the author supports. I'm pretty confident having a true champion behind POLICY and we will we see a different positive situation occur for POLICY. I believe if that was to happen, the collect data would flow like a flood as DKIM systems are encouraged not discouraged from supporting it. - Should we recharter instead for different work? If we can get a renewed focus for DKIM POLICY with a different editor. Yes. - Should we close the working group? I don't see any further useful outcome with a status quo. So yes, if we can not get a new set of supporting engineering eyes for POLICY. Are there objections to this? Does anyone want to convince us that there's interest and energy to keep it open and do more work? Barry, I'm sure you know has always been a high interest in a DKIM+POLICY layer. Its in the charter and its diminishing focus was not one due to primarily to technical merits but simply put we had the wrong person on it. It was clear and obvious conflict of interest and incompatible issue which should of been addressed long ago by the IETF. POLICY had no change with Levine behind. There was never a desire to address all the comments provided and the fact is there was never any updates to fix all the clear ambiguity expressed by so many. So lets get to the real issue. What you are really asking is about the future of POLICY, not the WG. I would like to see a WG whether as a continuation of this IETF-DKIM list or a new IETF-DKIM-POLICY WG to finally give us a chance to complete a solid DKIM+POLICY security protocol for DKIM without all the intentional anti-policy WG disruptive interference seen over the years. I personally believe that if the IETF can help give POLICY a WG chance to be designed right, I think you will see some real positive adoption, marketing and confidence for DKIM. But who knows if that is true or not. We don't but you (speaking in general) can not denied there has always been a strong interest for a DKIM POLICY layer - its even a chartered item. But we just never really had a chance. My concern is sincere. I still have hope DKIM can help tremendously in the ongoing email security fight against domain fraud. What I don't want to see come to a reality is the Cry Wolf comments such as one I received recently from a customer testing and exploring our new DKIM+POLICY implementation: The initial version for
