Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
We've had a bit of discussion in this thread (and elsewhere) about this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. I need to get a sense of whether there's significant support for it. Again, please keep arguments to a minimum, so it's clearer to me what the consensus is -- we've had the arguments going for a while now. I have the writeup almost ready for the IESG, and this issue has had enough responses for me to get a clear sense: We do not have consensus to make this change. I'm closing issue #25 as wontfix. Thanks, Hector, for laying the issue out clearly, and to others for reviewing and commenting. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Participant input: I proposes the following: 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. I don't like making up a new name for what we already have. I'd rather just call it the domain part of the 'From' address. There's also the issue, in defining this, that there may be multiple From addresses with different domain parts. In a case like this: From: Paul Simon p...@example.com, Art Garfunkel g...@example.net ...which domain do we use? 3.9. Output Requirements For each signature that verifies successfully or produces a TEMPFAIL result, the output of a DKIM verifier module MUST include the set of: o The domain name, taken from the d= signature tag; and o The result of the verification attempt for that signature. | Optional output are: | | o The Agent or User Identity (AUID) taken from i=, if any. | | o The Originating Domain Identity (ODID). Verifier output | MAY consider ODID when no signatures or invalid signatures | are found. The output MAY include other signature properties or result meta- data, including PERMFAILed or otherwise ignored signatures, for use by modules that consume those results. I find this Mostly Harmless[1], but unnecessary. As others have said, it's clear that identity assessors can use any information they like, and the contents of the RFC5322 From are included in that. I don't object to pointing out items that we think might be particularly useful, but I don't think we should be calling it output of the signature verifier. And, really, advice about the identity assessor should mostly be in the deployment document, not in the protocol document. In other words, as a participant, I prefer not to add this, but I wouldn't fight strongly against it. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Barry Leiba wrote: Participant input: I don't like making up a new name for what we already have. I'd rather just call it the domain part of the 'From' address. We already have an identity for it in section 2.3 - Author's Organization and that is to mean a domain.We labeled all others with acronyms for easier modeling, why not ODID. There's also the issue, in defining this, that there may be multiple From addresses with different domain parts. In a case like this: From: Paul Simon p...@example.com, Art Garfunkel g...@example.net which domain do we use? This was already discussed over the years and many felt the first one (see next paragraph, but ADSP leaves it open, see ADSP Section 2.3 and 3.0. This is no different than having multiple 3rd party DKIM-Signatures with different responsible SDID signers. Keep in mind the rarity of it too. The originating author is already a vetted input process at legitimate hosting systems, i.e. No *legitimate* System in the world allows a free FROM input field for users to freely enter not only just one unknown address but multiples as well. The only ones are those catering to such anonymity have already long been the part and the source of the problem. -- 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 - Keep your Eye on the Prize!
At 11:52 06-05-2011, Barry Leiba wrote: We've had a bit of discussion in this thread (and elsewhere) about this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. I need to get a sense of whether there's significant support for it. Again, please keep As I could not find any description of an interoperability issue in the arguments that have been made, I cannot support any change. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
SM wrote: At 11:52 06-05-2011, Barry Leiba wrote: We've had a bit of discussion in this thread (and elsewhere) about this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. I need to get a sense of whether there's significant support for it. Again, please keep As I could not find any description of an interoperability issue in the arguments that have been made, I cannot support any change. Section 1.1 says Readers are advised to be familiar with the material in [RFC4686], [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. What do you think will happen when they read the DKIM Service Architecture, Security and Deployment Consensus Built Documents, all peppered with Signing Practices concepts? Do you think they will wonder why 3.9 doesn't bother to mention anything regarding that large chunk in that pretty Software Engineer Process Model illustration? Oh well. -- 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 - Keep your Eye on the Prize!
On 5/8/2011 7:03 AM, Barry Leiba wrote: Participant input: I proposes the following: 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. I don't like making up a new name for what we already have. I'd rather just call it the domain part of the 'From' address. We might want to consider the benefits of consistency with existing documentation. Email Arch (RFC 5598): Section 2.1.1: Author - responsible for creating the message Section 2.2.1: Originator - ensures that a message is valid for posting and then submits it to a Relay Section 4.1.4: From:Author Sender: Originator So what, exactly, are the semantics intended by this new term. I find this Mostly Harmless[1], but unnecessary. Going to Draft is supposed to restrict changes to what is necessary, rather than what is whimiscally appealing to some folk. There is already a problem with people's believing that DKIM protects or validates the From: field contents and that a DKIM signature implies assurances about that field, more than the actual data integrity from signing to verifying. Adding a new term to refer to a portion of the From: field implies that there is an important need for the DKIM Signing specification to make that reference. This feeds the confusion about the role of a DKIM signature. That's not benignly unnecessary. That's actively counter-productive. 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 - Keep your Eye on the Prize!
Dave CROCKER wrote: On 5/8/2011 7:03 AM, Barry Leiba wrote: I proposes the following: 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. I don't like making up a new name for what we already have. I'd rather just call it the domain part of the 'From' address. We might want to consider the benefits of consistency with existing documentation. Email Arch (RFC 5598): Section 2.1.1: Author - responsible for creating the message Section 2.2.1: Originator - ensures that a message is valid for posting and then submits it to a Relay Section 4.1.4: From:Author Sender: Originator So what, exactly, are the semantics intended by this new term. See RFC5585, RFC4686 and RFC5863. Which by the way has nothing to do with the author but the author domain (ODID). We have long established the only single anchor we have in RFC5322 and one we must protect is the RFC5322.FROM and that is why is it the single only DKIM requirement for burning it into the signature. Since the DKIM has nothing to say regarding missing signers, the security is lost and is thus an unsecured protocol design to now allow the ODID to be checked per RFC5016, RFC5617, RFC5585, RFC4686 and RFC5863. Adding a new term to refer to a portion of the From: field implies that there is an important need for the DKIM Signing specification to make that reference. And it does in section 1.1 with the advisement for readers to be familiar: 1.1. DKIM Architecture Documents Readers are advised to be familiar with the material in [RFC4686], [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. This feeds the confusion about the role of a DKIM signature. Too late. The existing confusion is to create (1) functional specifications and requirements and then ignore it in your (2) technical specifications, thus confusing (3) implementors, making (4) testing payoffs much harder to achieve and (5) maintenance even worst to contain - your five phases of Software Engineering. That's not benignly unnecessary. That's actively counter-productive. See above. -- 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 - Keep your Eye on the Prize!
On 06/May/11 21:09, John R. Levine wrote: this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. Dave and Murray are right, Hector is not. +1, since we don't know precisely what output is actually used. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Alessandro Vesely wrote: On 06/May/11 21:09, John R. Levine wrote: this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. Dave and Murray are right, Hector is not. +1, since we don't know precisely what output is actually used. Therefore, since we don't know, we discourage usage, exploration. On the other hand, we encourage a single output for a MUST Trust Assessor Identity where by far, the majority of the receivers don't have. I will venture using pareto, over 80% and most likely more 95-99%. Wonderful. I suggest we do know how what output is being used or would be used if enabled or is a technical requirement: 1) Empirical Fact! We know SDID is showing a very low payoff and very useless utility with a majority of DKIM mail coming from unknown signers and spammers 2) Current Implementations API Fact! We know ODID is used for ADSP lookups, optionally or not. 3) Technical Fact! We don't know if AUID is part of anything outside of it being adding as another signing bit, but it is WRITTEN in the technical specification as a MAY for Output. I believe I am more RIGHT here than David and Murray and you. -- 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 - Keep your Eye on the Prize!
On May 6, 2011, at 12:09 PM, John R. Levine wrote: this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. Dave and Murray are right, Hector is not. +1. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Barry Leiba wrote: We've had a bit of discussion in this thread (and elsewhere) about this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. I need to get a sense of whether there's significant support for it. Again, please keep arguments to a minimum, so it's clearer to me what the consensus is -- we've had the arguments going for a while now. Barry, as chair BTW Barry, the proposal I made was this: http://mipassoc.org/pipermail/ietf-dkim/2011q2/016282.html Repeated here for those without editor URL launching support or disabled. -- Murray wrote: You want AUID and RFC5322.From added to the Output Requirements section explicitly. BTW, while RFC5322.From will satisfy requirements, I am proposing a new ODID identity (RFC5322.From.domain) since that is whats already extracted by APIs in order to do the current ADSP support. I proposes the following: 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. INFORMATIVE IMPLEMENTATION NOTE: The ODID and SDID are inputs for the optional Checking Signing Practices component as described in the DKIM Service Architecture [RFC5585] 3.9. Output Requirements For each signature that verifies successfully or produces a TEMPFAIL result, the output of a DKIM verifier module MUST include the set of: o The domain name, taken from the d= signature tag; and o The result of the verification attempt for that signature. | Optional output are: | | o The Agent or User Identity (AUID) taken from i=, if any. | | o The Originating Domain Identity (ODID). Verifier output | MAY consider ODID when no signatures or invalid signatures | are found. The output MAY include other signature properties or result meta- data, including PERMFAILed or otherwise ignored signatures, for use by modules that consume those results. See Section 6.1 for discussion of signature validation result codes. You might be able to figure out better text. - -- 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 - Keep your Eye on the Prize!
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Thursday, May 05, 2011 9:41 PM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize! This approach you have is an implementation conclusion. It is not part of the protocol. The protocol clearly says in 3.11: Upon successfully verifying the signature, a receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present. Therefore with no subjective consideration, no assertions, no philosophies, the protocol defines a process model of: trust = TrustIdentityAssessor(SDID [,AUID]) There is NO opinion about this! That is your DKIM Trust Protocol Model with a Mandatory SDID input and an optional AUID input. Actually, using your notation, it's: trust = TrustIdentityAssessor(SDID[, AUID[, s=[, t=[, l=[, x=[, ...]]) How far do we really need to go here? In order for this to work, your 3.9 Output Requirement MUST expose those two parameters at the very least. By saying MAY ... other, I maintain that it already does. To be consistent you have three protocol design tech writing choices: 1) Remove the second clause in that 3.11 3rd paragraph - problem fixed. 2) Add AUID to 3.9 as an optional output 3) Remove section 3.9 ...or the solution I'm beginning to like: 4) Alter 3.11 to match 3.9. This is what happens when you add something in the last minute without any consensus. It was just added - no consensus. After a short scan of the tracker item (#22) and the discussion thread, I found three people worked on the specific text and at least five (including those three) said they liked the result, versus one or two that disagreed. That sounded like rough consensus to me and we were still within the WGLC deadline, so I incorporated the change. Again, the Chair has the final say. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Murray S. Kucherawy wrote: -Original Message- Therefore with no subjective consideration, no assertions, no philosophies, the protocol defines a process model of: trust = TrustIdentityAssessor(SDID [,AUID]) There is NO opinion about this! That is your DKIM Trust Protocol Model with a Mandatory SDID input and an optional AUID input. Actually, using your notation, it's: trust = TrustIdentityAssessor(SDID[, AUID[, s=[, t=[, l=[, x=[, ...]]) How far do we really need to go here? As far are the protocol technical specification says it is. However, isn't these additional parameters not part of a Trust Assessor functionality and are part of the validation functionality? In principle, the RFC4871 process model prototyping using a dyadic FP (Functional Programming) methodology would be overall: MAIL.PAYLOAD= MAIL_FEED() VERIFY.OUTPUT = DKIM_VERIFY(MAIL.PAYLOAD) ACCESSOR.OUTPUT = DKIM_ACCESSORS(VERIFY.OUTPUT, MAIL.PAYLOAD) In this summary prototype, MAIL.PAYLOAD provides all the inputs (RFC5322 message) for both verification and for any inputs required for any assessors in the process. The only new data would be included within the VERIFY.OUTPUT and ASSESSOR.OUTPUT namespaces. With 3.9, VERIFY.OUTPUT is defined to be: VERIFY.OUTPUT.RESULT VERIFY.OUTPUT.SDID Without 3.9, the technical reading extraction would be: VERIFY.OUTPUT.RESULT VERIFY.OUTPUT.SDID VERIFY.OUTPUT.AUID and IMO, per RFCs 4686, 5016, 5617, 5585, 5863 it would be: VERIFY.OUTPUT.RESULT VERIFY.OUTPUT.SDID VERIFY.OUTPUT.AUID VERIFY.OUTPUT.ODID To exclude AUID and/or ODID, it would be a subjective conclusion for a specific implementation mandate. To be consistent you have three protocol design tech writing choices: 1) Remove the second clause in that 3.11 3rd paragraph - problem fixed. 2) Add AUID to 3.9 as an optional output 3) Remove section 3.9 or the solution I'm beginning to like: 4) Alter 3.11 to match 3.9. or take out 3.11 and like it was done for RFC5322.From, you can modify the two references to the unfortunate technically incorrect sentence in the abstract and section 1.2: DKIM separates the question of the identity of the signer of the message from the purported author of the message. What question are we separating? The association? It would be technically incorrect given the binding requirement. In lieu of ADSP, it may be a policy-based association separation but still an DKIM-based association of authenticity. As long as Purported Author is a fundamental requirement to be bound to the signature, it will always be an inherent association between the signer and author that can not be separated. Maybe it can be change to a more functionally correct description: DKIM provides a mechanism which allows for the separation of the authorized association|relationship of the identity of the message signer from any other agent or user identity, including the originating author domain. Anyway -- 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 - Keep your Eye on the Prize!
On 5/5/11 9:40 PM, Hector Santos wrote: Dave CROCKER wrote: I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, By garbage, I mean not guaranteed to have any useful meaning. So, I believe, it's essentially meaningless as far as the protocol can stipulate. Assertions of its semantics thus fall outside of the base DKIM spec. It's worth noting that Murray said 'could be'. But Murray's final paragraph has the essential points: within the scope of the DKIM Signing specification, the receive-side has no way to determine what the semantics of i= are, as we discussed at great length when formulating the Update RFC. But, then, folks on the list already know that. We have here is a failure to communicate. - Cool Hand Luke Dave, This approach you have is an implementation conclusion. It is not part of the protocol. The protocol clearly says in 3.11: Upon successfully verifying the signature, a receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present. Therefore with no subjective consideration, no assertions, no philosophies, the protocol defines a process model of: trust = TrustIdentityAssessor(SDID [,AUID]) There is NO opinion about this! That is your DKIM Trust Protocol Model with a Mandatory SDID input and an optional AUID input. In order for this to work, your 3.9 Output Requirement MUST expose those two parameters at the very least. There is no assertions or opinions - thats the protocol you defined. Now, when you begin to exclude it, then you mixing up implementation desires with subjective conclusion that really is not part of the protocol defined. There is some subjective information notes about the value, but that has nothing to do with the protocol you defined. To be consistent you have three protocol design tech writing choices: 1) Remove the second clause in that 3.11 3rd paragraph - problem fixed. 2) Add AUID to 3.9 as an optional output 3) Remove section 3.9 This is what happens when you add something in the last minute without any consensus. It was just added - no consensus. I must agree with Hector on this point. It seems the motivation to simplify DKIM has wrongly included removal of output information intended to be bound with the signature. It would be like SMTP later deciding not to include trace information intended to be bound with the message. While the i= may contain the email address of the author or the postmaster of the domain or simply an opaque tag, the meaning is NOT undefined. Its meaning IS defined by the signing domain. The whole point of DKIM was to establish a context for such information, especially information intended to be closely bound with the signature. Deprecating that aspect of DKIM overlooks many security aspects, and the valid and intended use of this information. What this parameter had been defined should ensure against any interoperability issues, but perhaps deserves a warning that it NOT be used by third parties who are unaware of the signing domains definition of this field. It would still be extremely useful within enterprise applications, for example. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
We've had a bit of discussion in this thread (and elsewhere) about this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. I need to get a sense of whether there's significant support for it. Again, please keep arguments to a minimum, so it's clearer to me what the consensus is -- we've had the arguments going for a while now. Barry, as chair On Wed, May 4, 2011 at 6:11 PM, Hector Santos hsan...@isdg.net wrote: Ah come on guys! We all know what the problems are, we know the sides and what colors we wear. Is it possible to come up with a compromise to solve this conflicts once and for all? Dave, don't you want receivers to follow RFC5585 design? If so, then what can't we get the Outputs described for that design to work? From what I can see, there are four variables: status REQUIRED SDID REQUIRED, MANDATORY for Trust Identity Assessor (see 2.7) AUID OPTIONAL, see 3.11 ODID OPTIONAL for Checking Signing Process (see RFC5585) We have the REQUIRED/MANDATORY identity you want. But you have the others too. What is technically wrong with this? -- Sincerely Hector Santos http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. Dave and Murray are right, Hector is not. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Murray, your technical *subjective* reasoning is not convincing. First, as for procedural issues, I have come to understand for bis work, how Hansen, Klensin and SM describes it. You do not seem to reflect the same advice and quite often in contradiction. In regards to AUID, the only technical *non-subjective protocol recommendation to consider is the one in section 3.11: Upon successfully verifying the signature, a receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present. It provides the non-subjective protocol technical justifications for both outputs to be part of the output requirements. Nothing else need to be said. Its called Software Engineering. Choosing not to include it is a subjective implementation reason. In regards to ODID, its a fundamental message header. Its technical history and importance should not be something to be explained. In DKIM, that fundamental messaging entity is reflected as the only single header requirement for signature binding and per RFC5585, RFC4686, RFC5017 and RFC5617 an essential part for security. Most important of all: DKIM can not mandate which is now a highly questionable protocol with highly subjective information in it with an highly isolated mandate for a mandatory single output with a MUST have requirement for a Trust Identity Assessor without *explicitly exposing* all the minimal outputs, especially when the default design excludes security protocol design considerations. Protocol implementation is whats it all about and for RFC4871bis, it is for specific implementation design only. If we want to exclude specific implementations, the Output Requirements needs to be more open with DKIM Complete information for receivers to better consider. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 04, 2011 4:22 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize! You want AUID and RFC5322.From added to the Output Requirements section explicitly. At least two other participants disagree on either technical or procedural grounds. 1) I have not seen any no arguments based on technical merits, or one that didn't have an substantial proof. Purely procedural and even SM showed your opinion on procedural (for BIS work) was not quite IETF correct. You're not reading our replies then. So here we go again, once more for the record, one of each: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. Moreover, the suggestion conflates protocol and implementation; you can already pass the AUID, the From: field, or any other value you want to an adjacent layer or module without requiring a change to the current wording of 3.9. The fact that some adjacent modules want or need it is not proscribed by the current wording either, so the proposed change is actually unnecessary. Procedural: Working group consensus to date has been to list only SDID as the required output, along with a status (see RFC5672, and RFC4871bis WGLC traffic). Adding a value to the list of outputs is in contradiction to the Draft Standards advancement process (see BCP9, Section 4.1.2). Only removing things is allowed. SM didn't correct my interpretation of BCP9, but rather highlighted another aspect of it. What he said and what I said are both correct. 2) There are at least four others (including myself) who agree with the ODID proposal of both variable or one of them. I've only seen one other that supports the RFC5322.From as being a mandatory output. So let's tackle that now too, for the record: Technical: The RFC5322.From is an unvetted value. The entire field could be garbage. It's inappropriate; see above, same reasons. Procedural: Adding a value, see above, same reasons. So what's the compromise? Your ball. You are the editor of the documents. Its up to you to reduce the conflicts with proposed compromising text. Murray, I am not your problem as much you believe, insist it is. I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, especially Section 5.3 which explains the role of the document editor. Contrary to what you seem to believe, it is not our job to find a way to slip your suggestion in to the document just because it is repeated often. Rather, a change to a standards track document, which RFC4871 and RFC5672 are, requires working group consensus and then similarly consensus
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Murray, your technical *subjective* reasoning is not convincing. First, as for procedural issues, I have come to understand for bis work, how Hansen, Klensin and SM describes it. You do not seem to reflect the same advice and quite often in contradiction. In regards to AUID, the only technical *non-subjective protocol recommendation to consider is the one in section 3.11: Upon successfully verifying the signature, a receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present. It provides the non-subjective protocol technical justifications for both outputs to be part of the output requirements. Nothing else need to be said. Its called Software Engineering. Choosing not to include it is a subjective implementation reason. In regards to ODID, its a fundamental message header. Its technical history and importance should not be something to be explained. In DKIM, that fundamental messaging entity is reflected as the only single header requirement for signature binding and per RFC5585, RFC4686, RFC5017 and RFC5617 an essential part for security. Most important of all: DKIM can not mandate which is now a highly questionable protocol with highly subjective information in it with an highly isolated mandate for a mandatory single output with a MUST have requirement for a Trust Identity Assessor without *explicitly exposing* all the minimal outputs, especially when the default design excludes security protocol design considerations. Protocol implementation is whats it all about and for RFC4871bis, it is for specific implementation design only. If we want to exclude specific implementations, the Output Requirements needs to be more open with DKIM Complete information for receivers to better consider. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 04, 2011 4:22 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize! You want AUID and RFC5322.From added to the Output Requirements section explicitly. At least two other participants disagree on either technical or procedural grounds. 1) I have not seen any no arguments based on technical merits, or one that didn't have an substantial proof. Purely procedural and even SM showed your opinion on procedural (for BIS work) was not quite IETF correct. You're not reading our replies then. So here we go again, once more for the record, one of each: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. Moreover, the suggestion conflates protocol and implementation; you can already pass the AUID, the From: field, or any other value you want to an adjacent layer or module without requiring a change to the current wording of 3.9. The fact that some adjacent modules want or need it is not proscribed by the current wording either, so the proposed change is actually unnecessary. Procedural: Working group consensus to date has been to list only SDID as the required output, along with a status (see RFC5672, and RFC4871bis WGLC traffic). Adding a value to the list of outputs is in contradiction to the Draft Standards advancement process (see BCP9, Section 4.1.2). Only removing things is allowed. SM didn't correct my interpretation of BCP9, but rather highlighted another aspect of it. What he said and what I said are both correct. 2) There are at least four others (including myself) who agree with the ODID proposal of both variable or one of them. I've only seen one other that supports the RFC5322.From as being a mandatory output. So let's tackle that now too, for the record: Technical: The RFC5322.From is an unvetted value. The entire field could be garbage. It's inappropriate; see above, same reasons. Procedural: Adding a value, see above, same reasons. So what's the compromise? Your ball. You are the editor of the documents. Its up to you to reduce the conflicts with proposed compromising text. Murray, I am not your problem as much you believe, insist it is. I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, especially Section 5.3 which explains the role of the document editor. Contrary to what you seem to believe, it is not our job to find a way to slip your suggestion in to the document just because it is repeated often. Rather, a change to a standards track document, which RFC4871 and RFC5672 are, requires working group consensus and then similarly consensus up the chain
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, and it can't be false either. I don't even know what false means in this context. It's just a value which is guaranteed to be within the to the d= domain's bailiwick. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
On 5/5/11 1:34 PM, Michael Thomas wrote: On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, and it can't be false either. I don't even know what false means in this context. It's just a value which is guaranteed to be within the to the d= domain's bailiwick. Agreed. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
-Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Thursday, May 05, 2011 1:35 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize! On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, and it can't be false either. I don't even know what false means in this context. It's just a value which is guaranteed to be within the to the d= domain's bailiwick. By garbage, I mean not guaranteed to have any useful meaning. Think of how it might be used by someone seeking to avoid accumulating negative reputation. The subdomain might not exist; it could be a string of random (though syntactically legal) characters. The local part might not have anything at all to do with an email address or other login ID that's valid on the signer or author systems, and may be unique per-message meaning it can't be used as input to an assessor in a useful way. So, I believe, it's essentially meaningless as far as the protocol can stipulate. Assertions of its semantics thus fall outside of the base DKIM spec. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, and it can't be false either. Perhaps the word stable would be more applicable. The d= value is tied to the DNS, is relatively stable, and the verifier can check that there's a key record in the DNS that matches the signature. The parts of the i= beyond what's in the d= are just an assertion by the signer with no semantics, verifiable or otherwise, and are no more useful than any other unverified assertion. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Dave CROCKER wrote: I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, By garbage, I mean not guaranteed to have any useful meaning. So, I believe, it's essentially meaningless as far as the protocol can stipulate. Assertions of its semantics thus fall outside of the base DKIM spec. It's worth noting that Murray said 'could be'. But Murray's final paragraph has the essential points: within the scope of the DKIM Signing specification, the receive-side has no way to determine what the semantics of i= are, as we discussed at great length when formulating the Update RFC. But, then, folks on the list already know that. We have here is a failure to communicate. - Cool Hand Luke Dave, This approach you have is an implementation conclusion. It is not part of the protocol. The protocol clearly says in 3.11: Upon successfully verifying the signature, a receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present. Therefore with no subjective consideration, no assertions, no philosophies, the protocol defines a process model of: trust = TrustIdentityAssessor(SDID [,AUID]) There is NO opinion about this! That is your DKIM Trust Protocol Model with a Mandatory SDID input and an optional AUID input. In order for this to work, your 3.9 Output Requirement MUST expose those two parameters at the very least. There is no assertions or opinions - thats the protocol you defined. Now, when you begin to exclude it, then you mixing up implementation desires with subjective conclusion that really is not part of the protocol defined. There is some subjective information notes about the value, but that has nothing to do with the protocol you defined. To be consistent you have three protocol design tech writing choices: 1) Remove the second clause in that 3.11 3rd paragraph - problem fixed. 2) Add AUID to 3.9 as an optional output 3) Remove section 3.9 This is what happens when you add something in the last minute without any consensus. It was just added - no consensus. -- 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 - Keep your Eye on the Prize!
On 5/4/2011 3:11 PM, Hector Santos wrote: Dave, don't you want receivers to follow RFC5585 design? If so, then RFC 5585 is not a 'design'. It has a diagram that describes an overall service. Also, the scope of its description is much larger than what is covered by the DKIM Signing specification. what can't we get the Outputs described for that design to work? From what I can see, there are four variables: status REQUIRED SDIDREQUIRED, MANDATORY for Trust Identity Assessor (see 2.7) AUIDOPTIONAL, see 3.11 ODIDOPTIONAL for Checking Signing Process (see RFC5585) We have the REQUIRED/MANDATORY identity you want. But you have the others too. What is technically wrong with this? It goes beyond the Update the working group and the IETF approved. It also seems to confuse protocol issues with implementation issues. 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 - Keep your Eye on the Prize!
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 04, 2011 3:11 PM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: [ietf-dkim] Output summary - Keep your Eye on the Prize! Ah come on guys! We all know what the problems are, we know the sides and what colors we wear. Is it possible to come up with a compromise to solve this conflicts once and for all? I'm game. Let's play. You want AUID and RFC5322.From added to the Output Requirements section explicitly. At least two other participants disagree on either technical or procedural grounds. So what's the compromise? So far all you've done is repeat the suggestion without any changes, so the others repeat their position without any changes. That's not a quest for compromise, it's a circular argument. Try proposing something else, perhaps. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Murray S. Kucherawy wrote: -Original Message- Ah come on guys! We all know what the problems are, we know the sides and what colors we wear. Is it possible to come up with a compromise to solve this conflicts once and for all? I'm game. Let's play. I hope that means play nice. You want AUID and RFC5322.From added to the Output Requirements section explicitly. At least two other participants disagree on either technical or procedural grounds. 1) I have not seen any no arguments based on technical merits, or one that didn't have an substantial proof. Purely procedural and even SM showed your opinion on procedural (for BIS work) was not quite IETF correct. 2) There are at least four others (including myself) who agree with the ODID proposal of both variable or one of them. So what's the compromise? Your ball. You are the editor of the documents. Its up to you to reduce the conflicts with proposed compromising text. Murray, I am not your problem as much you believe, insist it is. -- 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 - Keep your Eye on the Prize!
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 04, 2011 4:22 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize! You want AUID and RFC5322.From added to the Output Requirements section explicitly. At least two other participants disagree on either technical or procedural grounds. 1) I have not seen any no arguments based on technical merits, or one that didn't have an substantial proof. Purely procedural and even SM showed your opinion on procedural (for BIS work) was not quite IETF correct. You're not reading our replies then. So here we go again, once more for the record, one of each: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. Moreover, the suggestion conflates protocol and implementation; you can already pass the AUID, the From: field, or any other value you want to an adjacent layer or module without requiring a change to the current wording of 3.9. The fact that some adjacent modules want or need it is not proscribed by the current wording either, so the proposed change is actually unnecessary. Procedural: Working group consensus to date has been to list only SDID as the required output, along with a status (see RFC5672, and RFC4871bis WGLC traffic). Adding a value to the list of outputs is in contradiction to the Draft Standards advancement process (see BCP9, Section 4.1.2). Only removing things is allowed. SM didn't correct my interpretation of BCP9, but rather highlighted another aspect of it. What he said and what I said are both correct. 2) There are at least four others (including myself) who agree with the ODID proposal of both variable or one of them. I've only seen one other that supports the RFC5322.From as being a mandatory output. So let's tackle that now too, for the record: Technical: The RFC5322.From is an unvetted value. The entire field could be garbage. It's inappropriate; see above, same reasons. Procedural: Adding a value, see above, same reasons. So what's the compromise? Your ball. You are the editor of the documents. Its up to you to reduce the conflicts with proposed compromising text. Murray, I am not your problem as much you believe, insist it is. I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, especially Section 5.3 which explains the role of the document editor. Contrary to what you seem to believe, it is not our job to find a way to slip your suggestion in to the document just because it is repeated often. Rather, a change to a standards track document, which RFC4871 and RFC5672 are, requires working group consensus and then similarly consensus up the chain of approval. It is not up to us to encourage consensus or compromise for submitted ideas; it's up to the people making the submissions. That's you here. If you want the change, you do the legwork. So far I don't see consensus that the RFC5322.From or AUID additions to 3.9 is an allowable change procedurally, or a supported one technically. That's why it's not included. You may of course appeal to the chair if you have different information than I do, but that's where it stands. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html