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 - proposing ODID Originating Domain Identity
On 5/5/11 1:07 AM, Murray S. Kucherawy wrote: I think in the early days of DKIM most people assumed DKIM would become a protocol where: * the body hash and header hash, using various header fields, certifies the DKIM signature and * the DKIM signature certifies the body and header fields, that had been used to create the DKIM signature. The current RFC4871bis defines a protocol where: * the body hash and header hash, using various header fields, certifies the DKIM signature and * the DKIM signature doesn't say anything about the body and header fields, that had been used to create the DKIM signature. Well, if there is /real/ WG consensus that 4871bis is right in this respect, then so be it. But is there real consensus? Or is it just because of what Mike describes as The set of people paying attention now are extremely few. Why don't we see any recent contributions from the authors of RFC4871? (except for Mike then). Any WG only has the people contributing currently upon which to build consensus. We can't possibly hope to achieve something by requiring votes from past contributors if they've moved on or lost interest. Keep in mind, too, that the document still has to go to the entire IETF and then the IESG for review and evaluation before it gets published. It will get plenty of additional eyes on it to make sure we've done right. It seems to me there are a number of WG participants (and I'm one of them), who regret the fact that RFC4871bis does not make the few additional steps required to achieve the expectations of the early days: a protocol that not only provides a DKIM signature (and an important d= payload) but also a protocol that certifies body and (some) header fields. I fail to see why we don't take those one or two extra steps, to make DKIM a protocol with much more use potential. Suppose we do add a mechanism that allows a signer to make some assertion of the validity of the content of some header field or the body of the message. Won't spammers just make those assertions in an attempt to make you believe something that's untrue? I know I for one would be scared by a message that says This really is a message from eBay. Trust me! unless I have some additional way to verify or trust the claim itself. Excuse me for my poor English, I shouldn't have used the word 'certify' here. I'm not talking about validity of content. Were I used the word 'certify' I mean: if a DKIM signature verifies successfully, the consumer can be sure that the body of the message (or the part thereof indicated by l=) and the h= headers, used to construct this signature, has not been changed between signer and verifier, and there is a one-to-one relation between the h= headers and the corresponding headerlines in the header of the message, that leaves no room for ambiguity. And in my view neither the consumer nor the assessor should have to re-do the work of the verifier, to get the assurance, described in the previous line. Signer assertions can't be trusted unless you know for sure you can trust the signer. But DKIM has no way to tell you that. So this is not something DKIM can specify. Agreed. /rolf ___ 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 5/5/11 1:36 AM, Michael Thomas wrote: On 05/04/2011 03:55 PM, Rolf E. Sonneveld wrote: Well, I think you both are right in reading what my concern/objection against 4871bis is. And maybe you're also right in that RFC4871 wasn't that much different of RFC4871bis. I think in the early days of DKIM most people assumed DKIM would become a protocol where: * the body hash and header hash, using various header fields, certifies the DKIM signature and * the DKIM signature certifies the body and header fields, that had been used to create the DKIM signature. Rolf, By certify do you mean assert that they are true/correct/something along those lines? see the message I just sent to the list. /rolf ___ 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 05/05/2011 03:35 AM, Rolf E. Sonneveld wrote: Excuse me for my poor English, I shouldn't have used the word 'certify' here. I'm not talking about validity of content. Were I used the word 'certify' I mean: if a DKIM signature verifies successfully, the consumer can be sure that the body of the message (or the part thereof indicated by l=) and the h= headers, used to construct this signature, has not been changed between signer and verifier, and there is a one-to-one relation between the h= headers and the corresponding headerlines in the header of the message, that leaves no room for ambiguity. And in my view neither the consumer nor the assessor should have to re-do the work of the verifier, to get the assurance, described in the previous line. Yes, that sounds right. Excuse me because the list volume has been so high, but what's the problem? Btw, I _think_ the phrase appropriate here is data integrity. 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!
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 - proposing ODID Originating Domain Identity
On 5/3/11 4:25 PM, Murray S. Kucherawy wrote: Why does the output of DKIM need to include something when the consumer of that output already has that information? Because a consumer should/must not have to re-do the work of the DKIM verifier. Or put it differently: a consumer is just consuming the output of the DKIM verification process, it will rely on it (provided there's a trust relation between consumer and verifier), and it normally will not re-do the work of the DKIM verifier. It has no knowledge of DKIM rules (bottom up etc.). Just like a MUA has no information about how two MTA's exchange a mail over SMTP. The assertion you're making is that the consumer of an API shouldn't need to maintain any context; the API will give you back all the bits of context you need to continue as well as the answer you need. If you feed N bytes of data to a hash function, what you get back is the resulting hash, not the hash and the source data or maybe the hash and N. All of the context is still in the API consumer, not in the function that's giving you what you want. If you give RSA_Verify() a signature, a public key and a hash, it gives you back a 1 if they match and a 0 otherwise, not 1/0 and then some of that same information you gave it. The caller is the part of the system that knows what the answer is telling you, because it understands the nature of the function it called. So it is with DKIM: If you get back an indication from a verifier function that a signature verified, then the signature covered the lowest From: field that you presented to it. You know that because that's how the interface you're using was defined. An implementation certainly could give you back that From: field's contents (and OpenDKIM does, if you ask for it), but still I don't see any reason to make it mandatory. In the process of finding the bottom of the header stack, DKIM will have read all headers. DKIM must also count headers as it advances up the stack. Senders signing with DKIM likely do so to better protect recipients and to obtain higher use rates. While conventions regarding header limits may change, headers limited to one are unlikely to have these limits change due to security issues. It is also likely those using DKIM conform with current stricter requirements and can signify this simply by listing them in the signature header field. Refusing to validate malformed email is important to prevent DKIM results from being misleading. Counting header fields is trivial compared to public key cryptography. Not noticing deceptive pre-pended header fields may mean DKIM could cause more harm than good. Nothing in in DKIM's API needs to change for DKIM to provide the desired protections being sought. -Doug -Doug I might even go so far as to say returning that From: field is dangerous since it is not confirmed by anything, so DKIM (which is an authentication protocol) returning data that can't be validated, even if it was signed, is quite possibly asking for trouble. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ 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 5/3/11 4:25 PM, Murray S. Kucherawy wrote: I might even go so far as to say returning that From: field is dangerous since it is not confirmed by anything, so DKIM (which is an authentication protocol) returning data that can't be validated, even if it was signed, is quite possibly asking for trouble. This is a remarkable statement. DKIM's verification of the signing domain provides a basis upon which contents of the message may be trusted. That trust most certainly includes the important From header field. In fact, only the From header field MUST be included in the DKIM signature. As such, clearly defining what constitutes the From header field IS important. -Doug ___ 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 5/4/11 1:25 AM, Murray S. Kucherawy wrote: -Original Message- From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] Sent: Tuesday, May 03, 2011 3:56 PM To: Murray S. Kucherawy Cc: IETF DKIM WG Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Why does the output of DKIM need to include something when the consumer of that output already has that information? Because a consumer should/must not have to re-do the work of the DKIM verifier. Or put it differently: a consumer is just consuming the output of the DKIM verification process, it will rely on it (provided there's a trust relation between consumer and verifier), and it normally will not re-do the work of the DKIM verifier. It has no knowledge of DKIM rules (bottom up etc.). Just like a MUA has no information about how two MTA's exchange a mail over SMTP. The assertion you're making is that the consumer of an API shouldn't need to maintain any context; the API will give you back all the bits of context you need to continue as well as the answer you need. If you feed N bytes of data to a hash function, what you get back is the resulting hash, not the hash and the source data or maybe the hash and N. All of the context is still in the API consumer, not in the function that's giving you what you want. If you give RSA_Verify() a signature, a public key and a hash, it gives you back a 1 if they match and a 0 otherwise, not 1/0 and then some of that same information you gave it. The caller is the part of the system that knows what the answer is telling you, because it understands the nature of the function it called. So it is with DKIM: If you get back an indication from a verifier function that a signature verified, then the signature covered the lowest From: field that you presented to it. You know that because that's how the interface you're using was defined. For a scenario where a caller is calling a DKIM milter which in turn calls an API, this is all true. But DKIM will be/is deployed in many more scenario's. Consider scenario's like: * there can be one or more hops between verifier and consumer * between verifier and consumer MTA's can re-order From headers, * or remove From headers if there is more than one of them present. * What if Postini and MessageLabs are going to use DKIM for inbound traffic for their customers and want to communicate the DKIM verification results to the consumers within the mail infra of their customers? An implementation certainly could give you back that From: field's contents (and OpenDKIM does, if you ask for it), but still I don't see any reason to make it mandatory. I might even go so far as to say returning that From: field is dangerous since it is not confirmed by anything, so DKIM (which is an authentication protocol) returning data that can't be validated, even if it was signed, is quite possibly asking for trouble. But then DKIM is only authenticating the d= and we should no longer position DKIM as being 'effective in defending against the fraudulent use of origin addresses'. /rolf ___ 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
Rolf E. Sonneveld wrote: On 5/4/11 1:25 AM, Murray S. Kucherawy wrote: The assertion you're making is that the consumer of an API shouldn't need to maintain any context; the API will give you back all the bits of context you need to continue as well as the answer you need. .. So it is with DKIM: If you get back an indication from a verifier function that a signature verified, then the signature covered the lowest From: field that you presented to it. You know that because that's how the interface you're using was defined. For a scenario where a caller is calling a DKIM milter which in turn calls an API, this is all true. But DKIM will be/is deployed in many more scenario's. Consider scenario's like: * there can be one or more hops between verifier and consumer * between verifier and consumer MTA's can re-order From headers, * or remove From headers if there is more than one of them present. * What if Postini and MessageLabs are going to use DKIM for inbound traffic for their customers and want to communicate the DKIM verification results to the consumers within the mail infra of their customers? An implementation certainly could give you back that From: field's contents (and OpenDKIM does, if you ask for it), but still I don't see any reason to make it mandatory. I might even go so far as to say returning that From: field is dangerous since it is not confirmed by anything, so DKIM (which is an authentication protocol) returning data that can't be validated, even if it was signed, is quite possibly asking for trouble. But then DKIM is only authenticating the d= and we should no longer position DKIM as being 'effective in defending against the fraudulent use of origin addresses'. +1 well said. Let me show examples of the DKIM mail integration dilemmas. My apology for the length of this, but I am trying to extract all the key design issues we are facing or will be facing with DKIM: A fundamental flaw is to believe all backends have a RFC5322 Mail Store. The protocol has to provide for discovery for the software engineering interface points to engineer the integration and transformations needs. RFC4871bis is saying there is an mandatory interfacing point for a trust transformation and believing that leaving the door open with stating the possibility of other outputs is universally obvious. For a DKIM software engineering minimal, DKIM-BASE needs to expose the interface points such the ODID (or From) and the AUID which is explicitly stated as a MAY therefore it should also be part of the Outputs. Reasonable engineers to exptract from RFC5585, RFC4686 the interface points for the black box transformed outputs. There are only four minimal elements that can be extracted based on all the different considerations since RFC4871 with all the related consensus built documents: verification status SDID signer domain AUID agent/user identity ODID author domain Everyone will need those parameters to satisfy the DKIM Service Architecture which includes security, policy and trust considerations. When one actually begins to employ DKIM in a total mail systems that includes: - internet hosting with SMTP, POP3, NNTP, MLM, IMAP, etc, - how mail is stored and/or transformed, and - online/offline MUA considerations it become more clear of what inputs/utputs are needed for DKIM purposes and also the complexity of where the trust increases and decreases. Example: Remote UserA sends dkim signed mail to Local UserB and Local UserC at the same local mail host. UserB likes to use the Online Mail Access (Web site, but it can be any other online connection device). UserC was an online person, but he slowly migrated over the years to an offline RFC-based Mail Reader/Writer (Outlook, Eudora, Thunderbird and many others). UserB - online user. It should be fairly obvious that the centralized backend has rendering control for UserB and has all the power to provide the security, policy and overall trust outcomes the UserB. During the import process from remote userA, depending on the backend storage method, the information was generated necessary for the backend to display the information to the UserB. To assume the backend will do the verification dynamically with each message reader, while possible, probably not very efficient. So the odds are good the verification was be done once and all the outputs will need to be stored. Whether one is using a raw RFC54322 storage method or it is protocol assumed that is expected is not the point because in cases, the output must be common. What is important to consider is that it is backend that is telling UserB and all online access users is that what they see should be trusted (at least in the header display) UserC - Online User. Let uses POP3. Backends don't have control of what is display or how it will be
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
For a scenario where a caller is calling a DKIM milter which in turn calls an API, this is all true. But DKIM will be/is deployed in many more scenarios. Indeed, but you're misunderstanding the point of a standard. The DKIM spec tells signers how to create a signature that recipients can verify, and it tells verifiers how to check whether a signature is valid. The spec is not an implementation guide for every possible implementation scenario. We're allowed to assume that the spec will be implemented by reasonably competent programmers. I think reasonably competent includes figuring how to maintain or communicate the external state needed to do what you want to do. 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 5/4/2011 1:23 AM, Rolf E. Sonneveld wrote: But then DKIM is only authenticating the d= and we should no longer position DKIM as being 'effective in defending against the fraudulent use of origin addresses'. Besides your rather unusual sense of software architecture, your above statement seems to indicate a failure to attend to differences between rfc4871 and rfc4871bis. Which documentation makes your above claims? 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
John R. Levine wrote: For a scenario where a caller is calling a DKIM milter which in turn calls an API, this is all true. But DKIM will be/is deployed in many more scenarios. Indeed, but you're misunderstanding the point of a standard. The DKIM spec tells signers how to create a signature that recipients can verify, and it tells verifiers how to check whether a signature is valid. The spec is not an implementation guide for every possible implementation scenario. We're allowed to assume that the spec will be implemented by reasonably competent programmers. I think reasonably competent includes figuring how to maintain or communicate the external state needed to do what you want to do. Beside the point that there are conflicts, these are all valid points and the issue is beyond validity or rather how DKIM-BASE goes beyond the validity question. The mandatory single output for SDID attempts to mandate a specific receiver design implementation where the message is valid and trusted if they have the local or query method available for evaluating trust for SDID. It is a MUST design by DKIM-BASE standards and this SDID trust policy design mandate is not the issue for the receiver. We get it. The issue is that receivers also have serious security controls, anti-abuse operational needs. With the #1 market of signers being spammers increasing using DKIM in some silly idea that it will give them brownie points, DKIM redundant abuse will not be tolerated and it doesn't help DKIM to live in indeterministic world where SDID is unknown or provides no trust results. Reasonable competent manager, software engineers and programmers will look at the pretty picture called DKIM Service Architectures - we all like pictures - and determine very quickly what is the inputs and outputs. It shows in graphically process flow iconic form what is required and what is optional. The design issue is that not all outputs are not spelled out in the Functional Specification for DKIM. It doesn't match what RFC5595 calls the DKIM Service Architecture. RFC4871bis does not reflect what receivers need for security controls. -- 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 - proposing ODID Originating Domain Identity
On 5/4/11 3:29 PM, Dave CROCKER wrote: On 5/4/2011 1:23 AM, Rolf E. Sonneveld wrote: But then DKIM is only authenticating the d= and we should no longer position DKIM as being 'effective in defending against the fraudulent use of origin addresses'. Besides your rather unusual sense of software architecture, This comment is not very constructive, especially as it lacks any information about /what/ it is, that is unusual. your above statement seems to indicate a failure to attend to differences between rfc4871 and rfc4871bis. Which documentation makes your above claims? Both documents refer to rfc4686, albeit only in the Informative References section. rfc4871 refers to rfc4686 only in section 8, rfc4871bis in section 8 as well as in section 1.1. Please provide us some pointers regarding the differences between rfc4871 and rfc4871bis in relation to the above statement. /rolf ___ 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 5/4/2011 7:04 AM, Rolf E. Sonneveld wrote: Which documentation makes your above claims? Both documents refer to rfc4686, albeit only in the Informative References section. rfc4871 refers to rfc4686 only in section 8, rfc4871bis in section 8 as well as in section 1.1. Please provide us some pointers regarding the differences between rfc4871 and rfc4871bis in relation to the above statement. The claim that rfc4871bis has the goal you claim is yours. So you need to do the work of subtantiating it. So far, as you acknowledge, your only reference is quite old, merely informative, and not a specification. In contrast, rfc4871bis declares the goal of its specification and it's not the one you assert. You've now had multiple people responding to this thread with various explanations why it is off the mark. We should be done. 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
Dave CROCKER wrote: On 5/4/2011 7:04 AM, Rolf E. Sonneveld wrote: Which documentation makes your above claims? Both documents refer to rfc4686, albeit only in the Informative References section. rfc4871 refers to rfc4686 only in section 8, rfc4871bis in section 8 as well as in section 1.1. Please provide us some pointers regarding the differences between rfc4871 and rfc4871bis in relation to the above statement. The claim that rfc4871bis has the goal you claim is yours. It showed that. Are you suggesting security is not part of DKIM's goal? So you need to do the work of subtantiating it. The proof of concept was done in the WG consensus built RFC4686 security document. So far, as you acknowledge, your only reference is quite old, merely informative, and not a specification. In contrast, rfc4871bis declares the goal of its specification and it's not the one you assert. Exactly the point, it doesn't reflect current implementation needs yet has inconsistencies where any reasonable engineers can presumed the design is beyond what you attempting to mandate for receivers. You've now had multiple people responding to this thread with various explanations why it is off the mark. But there are multiple people who disagree with those explanations and agree Rolf is right on mark. We should be done. We should of been done long ago. IETF needs to consider why you are having a hard time explaining away the security concerns for almost 5 years now. You need to rethink why reasonable compromising solutions offered should be ignored and rudely shunned out. You need to consider good nature WG participant perspectives to help DKIM better fit receiver needs and considering ODID (and AUID) is compatible with the DKIM goal. -- 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 - proposing ODID Originating Domain Identity
On 05/04/2011 07:08 AM, Dave CROCKER wrote: The claim that rfc4871bis has the goal you claim is yours. So you need to do the work of subtantiating it. So far, as you acknowledge, your only reference is quite old, merely informative, and not a specification. In contrast, rfc4871bis declares the goal of its specification and it's not the one you assert. You've now had multiple people responding to this thread with various explanations why it is off the mark. We should be done. This is a good example of why this effort has come off the rails. Going from 4871 to DS should have been a fairly straightforward effort considering the high degree of interoperability we achieved. Instead of just removing a few unused features, we've seen a wholesale rewrite when one was manifestly not needed. Worse, is that when that history is mentioned it is either disregarded or sneered at by the senior editor. That is a problem. This entire process needs a reset, starting with the choice of editors. We are so far afield of what RFC 4871 was that it's impossible to understand the implications of the subtle changes that have been introduced. RFC 4871 worked. It did not need anywhere close to this level of fixing. Mike ___ 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
Michael, On 5/4/2011 7:58 AM, Michael Thomas wrote: This is a good example of why this effort has come off the rails. Going from 4871 to DS should have been a fairly straightforward effort considering the high degree of interoperability we achieved. Instead of just removing a few unused features, we've seen a wholesale rewrite when one was manifestly not needed. Worse, is that when that history is mentioned it is either disregarded or sneered at by the senior editor. That is a problem. Wholesale rewrite? Well, that should be easy for you to document, given how convenient it is to point to the existing diffs. The task when citing a problem with changes is to point to /specific/ changes that are problematic. That requires some work. In particular, please cite normative differences. As for the particular difference between rfc4871's statement of DKIM's purpose and rfc4871bis' statement, you might want to review the language in the Service Overview and the Deployment documents. On this issue, the working group's learning process has been incremental and well documented. As for 'sneering' at history, please do cite that occurrence, too. Please distinguish between citing history versus sneering at it. Explaining the criteria that qualifies as 'sneering' would be helpful. I am also surprised to discover that we have any junior editors or, for that matter, that editors are distinguished by seniority. 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: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Wednesday, May 04, 2011 7:59 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Going from 4871 to DS should have been a fairly straightforward effort considering the high degree of interoperability we achieved. Instead of just removing a few unused features, we've seen a wholesale rewrite when one was manifestly not needed. Has anyone other than me bothered to generate and review the complete diff? This is a gross exaggeration of what's actually changed. ___ 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 05/04/2011 08:16 AM, Dave CROCKER wrote: Michael, On 5/4/2011 7:58 AM, Michael Thomas wrote: This is a good example of why this effort has come off the rails. Going from 4871 to DS should have been a fairly straightforward effort considering the high degree of interoperability we achieved. Instead of just removing a few unused features, we've seen a wholesale rewrite when one was manifestly not needed. Worse, is that when that history is mentioned it is either disregarded or sneered at by the senior editor. That is a problem. Wholesale rewrite? Well, that should be easy for you to document, given how convenient it is to point to the existing diffs. The task when citing a problem with changes is to point to /specific/ changes that are problematic. That requires some work. In particular, please cite normative differences. As I've already mentioned: the notion of output is a huge NORMATIVE change. It should have never been allowed as a piece of errata, and continues to cause all manner of issues. 4871 was NOT BROKEN in this respect. We have no business telling developers what the layering relationship is between the DKIM verifier and its consumers. As for the particular difference between rfc4871's statement of DKIM's purpose and rfc4871bis' statement, you might want to review the language in the Service Overview and the Deployment documents. On this issue, the working group's learning process has been incremental and well documented. Asleep at the switch is a more accurate portrayal. By the time any of this effort started, we had a wealth of interoperability information which resulted in the non-controversial parts of the errata, and stable unchanging implementations. The learning should be to leave well enough alone, instead of changing things just for aesthetics and quite likely breaking things in the process, either purposefully or inadvertently. As for 'sneering' at history, please do cite that occurrence, too. Please distinguish between citing history versus sneering at it. Explaining the criteria that qualifies as 'sneering' would be helpful. You need look only at the piece that I quoted from. Your continuous use of ad hominem attacks is well documented. Mike ___ 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: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Rolf E. Sonneveld Sent: Wednesday, May 04, 2011 7:04 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Both documents refer to rfc4686, albeit only in the Informative References section. rfc4871 refers to rfc4686 only in section 8, rfc4871bis in section 8 as well as in section 1.1. There are two main fallacies that appear to be behind the arguments of a few people here: (1) RFC4686 is gospel. It isn't. Its status is Informative which means it doesn't bind anyone to do anything. (2) A working group is not entitled to change its mind about something based on experience. It is. Since RFC4686 was published, some of the consensus view of how this does/should/might all work has shifted. There's nothing wrong with that. If someone wants to undertake the work of publishing an update because it's seen as important, there are several of us that could assist with procedure, though it's unlikely to be done by this working group at this point. ___ 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 05/04/2011 08:51 AM, Murray S. Kucherawy wrote: Both documents refer to rfc4686, albeit only in the Informative References section. rfc4871 refers to rfc4686 only in section 8, rfc4871bis in section 8 as well as in section 1.1. There are two main fallacies that appear to be behind the arguments of a few people here: (1) RFC4686 is gospel. It isn't. Its status is Informative which means it doesn't bind anyone to do anything. (2) A working group is not entitled to change its mind about something based on experience. It is. Since RFC4686 was published, some of the consensus view of how this does/should/might all work has shifted. There's nothing wrong with that. If someone wants to undertake the work of publishing an update because it's seen as important, there are several of us that could assist with procedure, though it's unlikely to be done by this working group at this point. My sense is that what Rolf is asking at its base is that the there is a conflict between the two documents and it's not clear why they exist, and which should be believed. If 4686 is inconsistent, then we should make a case for why it's wrong and document that. It may be process-wise informational, but it served at the time as a guiding document for the creation of 4871, and had working group consensus at a time of extremely high scrutiny. We do not have anywhere close to that level of scrutiny now, and as such any changes made should be viewed with a very high level of caution and scepticism. Mike ___ 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 5/4/2011 8:18 AM, Murray S. Kucherawy wrote: Has anyone other than me bothered to generate and review the complete diff? I've uploaded Murray's helpful effort to the DKIM site: http://dkim.org/specs/rfc4871-to-bis02-diff.htm I had assumed that the complete diff would be unreadable, which is why I originally put up the incremental diffs. However in looking through the complete diff, I'm surprised to discover that it is quite easy to see and evaluate all of the changes. We really ought to stop responding to criticisms that provide no substantiation. For criticism to be constructive, it needs to contain meaningful substance. Complaining is easy; substantiating criticism takes effort. 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: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 9:03 AM To: Murray S. Kucherawy Cc: Rolf E. Sonneveld; dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity My sense is that what Rolf is asking at its base is that the there is a conflict between the two documents and it's not clear why they exist, and which should be believed. If 4686 is inconsistent, then we should make a case for why it's wrong and document that. It may be process-wise informational, but it served at the time as a guiding document for the creation of 4871, and had working group consensus at a time of extremely high scrutiny. We do not have anywhere close to that level of scrutiny now, and as such any changes made should be viewed with a very high level of caution and scepticism. My read is that Rolf is objecting to RFC4871bis on the grounds that it conflicts with RFC4686. (He can and should correct me if I'm wrong.) If his concerns would be satisfied by a change (perhaps an appendix?) that simply acknowledges some evolution in thinking based on experience since RFC4686 was published, I imagine that wouldn't meet with much resistance. But if the point is to use RFC4686 to compel some change in something trying to get to DS (or even PS), that's a non-starter. ___ 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
Dave CROCKER wrote: Michael, On 5/4/2011 7:58 AM, Michael Thomas wrote: This is a good example of why this effort has come off the rails. Going from 4871 to DS should have been a fairly straightforward effort considering the high degree of interoperability we achieved. Instead of just removing a few unused features, we've seen a wholesale rewrite when one was manifestly not needed. Worse, is that when that history is mentioned it is either disregarded or sneered at by the senior editor. That is a problem. Wholesale rewrite? Well, that should be easy for you to document, given how convenient it is to point to the existing diffs. The task when citing a problem with changes is to point to /specific/ changes that are problematic. That requires some work. In particular, please cite normative differences. Its absolutely amazing how the main points are just blow away. Wow! #1 NEW - The key difference as so many others has stated is the MANDATORY mandate for the single output, SDID, with a MUST design mandate for a futuristic single Trust Identity Assessor module. #2 NEW - RFC4871bis introduces the AUID identity as a MAY for the trust module, *yet* this optional consideration is excluded from the RFC4871bis Output Requirements. Incidentally, my concerns as well of many other implementors predated RFC4871 (2007 publication) with the drafting leading to the separation of policy and all policy related semantics from the base. This was a major concerns cited by many including the prediction that policy will be not be completed as a standard. The goal was to remove the Author Domain (ODID) from DKIM and move it to *purported* chartered proposed standard for policy, then called SSP. We completed WG consensus built requirements SSP document (RFC5017) and eventually ADSP (RFC5617). In the name of protocol consistency and synergism with completed chartered RFC work products, it is only natural to expect the ODID MUST be part of the output identities for RFC4871BIS which should reflect all the RFC work that was done since RFC4871. Instead we have: #3 NEW: RFC4871BIS Output requirements that do not reflect any other work that as done, including this so called DKIM Service Architecture. -- 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 - proposing ODID Originating Domain Identity
Folks, I've uploaded Murray's helpful effort to the DKIM site: http://dkim.org/specs/rfc4871-to-bis02-diff.htm apologies. my html editor got sticky. i guess it really liked the earlier diff. The full diff that I meant to point to is: http://dkim.org/specs/dkim-rfc4871-rfc-bis-diff.html 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
On 05/04/2011 09:15 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 9:03 AM To: Murray S. Kucherawy Cc: Rolf E. Sonneveld; dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity My sense is that what Rolf is asking at its base is that the there is a conflict between the two documents and it's not clear why they exist, and which should be believed. If 4686 is inconsistent, then we should make a case for why it's wrong and document that. It may be process-wise informational, but it served at the time as a guiding document for the creation of 4871, and had working group consensus at a time of extremely high scrutiny. We do not have anywhere close to that level of scrutiny now, and as such any changes made should be viewed with a very high level of caution and scepticism. My read is that Rolf is objecting to RFC4871bis on the grounds that it conflicts with RFC4686. (He can and should correct me if I'm wrong.) If his concerns would be satisfied by a change (perhaps an appendix?) that simply acknowledges some evolution in thinking based on experience since RFC4686 was published, I imagine that wouldn't meet with much resistance. But if the point is to use RFC4686 to compel some change in something trying to get to DS (or even PS), that's a non-starter. Compel and non-starter are not helpful. Everything past publication of 4871 should be viewed in the light that fewer and fewer people were paying attention. The set of people paying attention now are extremely few, and many of them have self-interest in revisiting and/or changing the previous consensus -- taking advantage of the much smaller set of participants. Not that 4686 and 4871 are some sort of ideal residing in a platonic cave, but they do have the virtue that they were widely reviewed and in the case of 4871, implemented. We risk screwing things up with every edit; the law of unintended consequences isn't being given the respect it deserves. Mike ___ 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: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 04, 2011 9:17 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Its absolutely amazing how the main points are just blow away. Wow! Can we remain professional, please? This flare for the dramatic only drags the group down further into the mire (as if that's possible). #1 NEW - The key difference as so many others has stated is the MANDATORY mandate for the single output, SDID, with a MUST design mandate for a futuristic single Trust Identity Assessor module. I can't imagine any successful DKIM verifier module based on RFC4871 that didn't output at least the SDID and a status for the signature, for each signature. Thus, saying so in RFC4871bis doesn't seem to me to be a normative change that breaks anything. This is completely appropriate in another way: The SDID from a valid signature is the only thing that DKIM proves. #2 NEW - RFC4871bis introduces the AUID identity as a MAY for the trust module, *yet* this optional consideration is excluded from the RFC4871bis Output Requirements. It's true that the AUID is not listed as mandatory output, but that section very clearly states that a verifier could output other stuff, including the AUID, to a module that wants it. I can't imagine any DKIM verifier module based on RFC4871 that would thus become non-compliant when compared to RFC4871bis. But the AUID is only partially proven by DKIM; the local-part, for example, is potentially garbage, as is the subdomain. So it makes sense not to make it a mandatory output of a security protocol. So, please read the Output Requirements again and explain to me the basis for this claim. Incidentally, my concerns as well of many other implementors predated RFC4871 (2007 publication) with the drafting leading to the separation of policy and all policy related semantics from the base. This was a major concerns cited by many including the prediction that policy will be not be completed as a standard. And such separation occurred. And it was good. The goal was to remove the Author Domain (ODID) from DKIM and move it to *purported* chartered proposed standard for policy, then called SSP. We completed WG consensus built requirements SSP document (RFC5017) and eventually ADSP (RFC5617). Right. In the name of protocol consistency and synergism with completed chartered RFC work products, it is only natural to expect the ODID MUST be part of the output identities for RFC4871BIS which should reflect all the RFC work that was done since RFC4871. No, that's not natural. Instead we have: #3 NEW: RFC4871BIS Output requirements that do not reflect any other work that as done, including this so called DKIM Service Architecture. -1. RFC4871bis very clearly includes all the work that's been done, unless you have some other input that hasn't been revealed to date. ___ 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 05/04/2011 09:14 AM, Dave CROCKER wrote: I've uploaded Murray's helpful effort to the DKIM site: http://dkim.org/specs/rfc4871-to-bis02-diff.htm I had assumed that the complete diff would be unreadable, which is why I originally put up the incremental diffs. However in looking through the complete diff, I'm surprised to discover that it is quite easy to see and evaluate all of the changes. We really ought to stop responding to criticisms that provide no substantiation. For criticism to be constructive, it needs to contain meaningful substance. Complaining is easy; substantiating criticism takes effort. 44 pages of diffs. That is not by stretch of the imagination inconsequential. I count at least two new normative changes -- in informational notes of all places -- by scanning *half* the document, both of which are wrong. And that does not count the normative change with Output. Thanks for reinforcing my impression that this is a process run amok. Mike ___ 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: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Wednesday, May 04, 2011 10:11 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity 44 pages of diffs. Updating an RFC number causes a diff. That's not a valid metric. I count at least two new normative changes -- in informational notes of all places -- by scanning *half* the document, both of which are wrong. And that does not count the normative change with Output. Where are they? Thanks for reinforcing my impression that this is a process run amok. Not so fast... ___ 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 05/04/2011 10:13 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Wednesday, May 04, 2011 10:11 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity 44 pages of diffs. Updating an RFC number causes a diff. That's not a valid metric. These aren't updates to just the rfc number though. This document has been changing and changing and changing up until the weeks before last call, and through last call. It's impossible to keep up with unless it is your full time job, which it most certainly isn't in my case -- unless you can figure out how this relates to public key substitution attacks in android market in-app purchases. That is why I'm so alarmed. Mike ___ 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: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:21 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity 44 pages of diffs. Updating an RFC number causes a diff. That's not a valid metric. These aren't updates to just the rfc number though. This document has been changing and changing and changing up until the weeks before last call, and through last call. It's impossible to keep up with unless it is your full time job, which it most certainly isn't in my case -- unless you can figure out how this relates to public key substitution attacks in android market in-app purchases. That is why I'm so alarmed. Ah, you deftly avoided my question: You said: I count at least two new normative changes -- in informational notes of all places -- by scanning *half* the document, both of which are wrong. What were the two normative changes in informational notes that were wrong in the half of the document you scanned? ___ 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 05/04/2011 10:25 AM, Murray S. Kucherawy wrote: I count at least two new normative changes -- in informational notes of all places -- by scanning *half* the document, both of which are wrong. What were the two normative changes in informational notes that were wrong in the half of the document you scanned? It's because I didn't want to imply that those were the only two. It's just what I found in my quick scan. But they were the advise about ignoring signatures with sha1, and another saying you could ignore an l= *tag*. And that's what I found in 15 minutes. Mike ___ 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
Has anyone other than me bothered to generate and review the complete diff? I have. The changes to the parts that actually describe how to create a signature are tiny, and well contained, e.g. updating the punycode definition, making sha-1 more deprecated, clarifying that unknown options and flags are ignored, explicitly deleting whitespace around b= when computing signatures, notes that all bets are off if you start with an invalid message. 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
-Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:29 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity It's because I didn't want to imply that those were the only two. It's just what I found in my quick scan. But they were the advise about ignoring signatures with sha1, and another saying you could ignore an l= *tag*. I can't recall the history of the first one, other than it being consistent with general IETF movement away from use of SHA1. Perhaps someone else can comment there. The advice that a verifier can ignore the l= tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me. ___ 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 5/4/2011 9:15 AM, Murray S. Kucherawy wrote: My read is that Rolf is objecting to RFC4871bis on the grounds that it conflicts with RFC4686. (He can and should correct me if I'm wrong.) If his concerns would be satisfied by a change (perhaps an appendix?) that simply acknowledges some evolution in thinking based on experience since RFC4686 was published, I imagine that wouldn't meet with much resistance. My reading of the concern is specifically that the statement of DKIM's goal has been refined over time and that all that might be useful for the current document is to cite that fact and, perhaps, compare original versus current statements. The appendix to do that would be very short. It perhaps should cite the incremental changes across the sequence of wg documents and explain the salient meaning of the change, but in informative and not normative terms. If there is more material at issue, what is it? 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
On 05/04/2011 10:43 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:29 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity It's because I didn't want to imply that those were the only two. It's just what I found in my quick scan. But they were the advise about ignoring signatures with sha1, and another saying you could ignore an l= *tag*. I can't recall the history of the first one, other than it being consistent with general IETF movement away from use of SHA1. Perhaps someone else can comment there. Saying that receivers can ignore signatures with sha1 is a serious difference. What does that do for interoperability if followed? Nothing good is my guess. The advise I've always heard is walk, but don't run away from sha1. Let's be real: DKIM's crypto guarantees are already low; sha1 is the least of its weaknesses. The advice that a verifier can ignore the l= tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me. You can't ignore the *tag*. That's the normative change. Whether you ignore the *output* is another matter. But of course you can't ignore the output because l= is internal. Yet another problem. Mike ___ 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
Murray S. Kucherawy wrote: Its absolutely amazing how the main points are just blow away. Wow! Can we remain professional, please? This flare for the dramatic only drags the group down further into the mire (as if that's possible). My apology but please view that take like I'm giving up, You should read the specs correctly, Please Stop, We should be done. etc, none attributed anyone person, does make anyone giggle either. #1 NEW - The key difference as so many others has stated is the MANDATORY mandate for the single output, SDID, with a MUST design mandate for a futuristic single Trust Identity Assessor module. I can't imagine any successful DKIM verifier module based on RFC4871 that didn't output at least the SDID and a status for the signature, for each signature. Thus, saying so in RFC4871bis doesn't seem to me to be a normative change that breaks anything. I don't think u read this right. Not saying it is bad - but its the only receiver mandate at the expense of others. No mandate can tell receivers what to do. All options need to be presented. This is completely appropriate in another way: The SDID from a valid signature is the only thing that DKIM proves. Ok, very good. It tells you the payoff value for SDID and its ok, to say its a mandatory identity receivers to look at. but its should be the exclusive one highlighted. #2 NEW - RFC4871bis introduces the AUID identity as a MAY for the trust module, *yet* this optional consideration is excluded from the RFC4871bis Output Requirements. It's true that the AUID is not listed as mandatory output, but that section very clearly states that a verifier could output other stuff, including the AUID, to a module that wants it. It clearly stated the obvious but not specific enough with DKIM related semantics - Being Specific is Terrific! I can't imagine any DKIM verifier module based on RFC4871 that would thus become non-compliant when compared to RFC4871bis. I didn't make that claim. What I said is that it hasn't learned. But the AUID is only partially proven by DKIM; the local-part, for example, is potentially garbage, as is the subdomain. So it makes sense not to make it a mandatory output of a security protocol. The problem here is that we are trying to dictate how to use it. DKIM did it write in abstract terms and it should continue with that exposure. You don't have to get into the details and that because AUID is still controversial, but making it available will prepare for the future. Personally, I think the definition for it be the SDID domain or subdomain should be a MAY and to begin teaching verifiers that a mismatch should not invalidate the signature which is only a domain comparison check and not a hash bound violation issue. So, please read the Output Requirements again and explain to me the basis for this claim. See above. The goal was to remove the Author Domain (ODID) from DKIM and move it to *purported* chartered proposed standard for policy, then called SSP. We completed WG consensus built requirements SSP document (RFC5017) and eventually ADSP (RFC5617). Right. In the name of protocol consistency and synergism with completed chartered RFC work products, it is only natural to expect the ODID MUST be part of the output identities for RFC4871BIS which should reflect all the RFC work that was done since RFC4871. No, that's not natural. Well, who's right you or me? I think its natural engineering to be protocol consistent among all integrated parts. Instead we have: #3 NEW: RFC4871BIS Output requirements that do not reflect any other work that as done, including this so called DKIM Service Architecture. -1. RFC4871bis very clearly includes all the work that's been done, unless you have some other input that hasn't been revealed to date. I stated what I believe are the four minimal extracts for DKIM output and mail integration: signature verify status SDID AUID ODID -- 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 - proposing ODID Originating Domain Identity
-Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:54 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity The advice that a verifier can ignore the l= tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me. You can't ignore the *tag*. That's the normative change. Whether you ignore the *output* is another matter. But of course you can't ignore the output because l= is internal. Yet another problem. But RFC4871 also said you could ignore the tag, so I don't understand the distinction you're making. ___ 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 05/04/2011 11:03 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:54 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity The advice that a verifier can ignore the l= tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me. You can't ignore the *tag*. That's the normative change. Whether you ignore the *output* is another matter. But of course you can't ignore the output because l= is internal. Yet another problem. But RFC4871 also said you could ignore the tag, so I don't understand the distinction you're making. Like I said, i only looked at this for a few minutes -- 4871 is wrong or sloppy here too. But my other objection still stands: with the procrustean output as it stand right now, an upper level entity would not be able to ignore signatures with l= because that's internal. Mike ___ 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
Dave, Sure, you can add an new appendix to justify the inconsistencies but it still doesn't resolve the issue of not exposing the in-scope parameters to satisfy the DKIM Service Architecture and all receiver needs related to DKIM. The mandate to impose a certain behavior is unrealistic and does not represent current implementations. This may not be an interest to you, but it to others. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Dave CROCKER wrote: On 5/4/2011 9:15 AM, Murray S. Kucherawy wrote: My read is that Rolf is objecting to RFC4871bis on the grounds that it conflicts with RFC4686. (He can and should correct me if I'm wrong.) If his concerns would be satisfied by a change (perhaps an appendix?) that simply acknowledges some evolution in thinking based on experience since RFC4686 was published, I imagine that wouldn't meet with much resistance. My reading of the concern is specifically that the statement of DKIM's goal has been refined over time and that all that might be useful for the current document is to cite that fact and, perhaps, compare original versus current statements. The appendix to do that would be very short. It perhaps should cite the incremental changes across the sequence of wg documents and explain the salient meaning of the change, but in informative and not normative terms. If there is more material at issue, what is it? d/ ___ 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 5/4/2011 9:47 AM, Michael Thomas wrote: The set of people paying attention now are extremely few, and many of them have self-interest in revisiting and/or changing the previous consensus -- taking advantage of the much smaller set of participants. Creative premise. Your assertion is that folks outside the wg are not monitoring it. Given the continuing, intense attention to DKIM that is taking place at a variety of vendues, such as MAAWG and some private industry groups, your assertion does not match the experience a number of us have. On 5/4/2011 10:29 AM, Michael Thomas wrote: It's because I didn't want to imply that those were the only two. It's just what I found in my quick scan. But they were the advise about ignoring signatures with sha1, and another saying you could ignore an l= *tag*. So apparently we've moved from a claim of normative changes to citation of advice, apparently with the claim that the advice is problematic. Perhaps I'm not understanding, but highlighting security differences, such as opening a hole with l= or a protection weakness by using an older algorithm is not unusual and it's difficult to see what is wrong with reminding an receiver that their acceptance of data are voluntary. And that's what I found in 15 minutes. Does this mean that 20 minutes work is too much to expect from someone making basic criticisms of months of wg effort? Once again: folks who participate seriously in an IETF working group and who have substantive concerns have an obligation to provide the substance that justifies the concern. They are generally also expected to put effort into proposing the details of a solution. Such is the nature of constructive participation. One can, of course, always find creative excuses for not participating on that basis. On 5/4/2011 10:29 AM, Michael Thomas wrote: On 05/04/2011 10:25 AM, Murray S. Kucherawy wrote: What were the two normative changes in informational notes that were wrong in the half of the document you scanned? It's because I didn't want to imply that those were the only two. This is quite a remarkable premise for refusing to provide concrete substance. I'm trying to imagine how a working group could ever make progress, were this premise prevalent. Don't offer substance without providing a massive tome to cover everything that qualifies it enough to avoid misunderstanding what hasn't been said... 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
On 5/4/2011 10:13 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Wednesday, May 04, 2011 10:11 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity 44 pages of diffs. Updating an RFC number causes a diff. That's not a valid metric. Since the diff is a side-by-side, it's worth noting that it's only 2/3 the length of the full document. But indeed it's an example of a statistic that is objectively accurate and functionally misleading. Just how onerous is it to look through that diff, enough to get a sense of the changes? 1/2-hour? 1 Hour? Is that onerous, when seeking to put forward fundamental criticisms of months of working group effort? 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
Hector Santos wrote: Murray wrote: This is completely appropriate in another way: The SDID from a valid signature is the only thing that DKIM proves. Ok, very good. It tells you the payoff value for SDID and its ok, to say its a mandatory identity receivers to look at. but its should be the exclusive one highlighted. Sorry, I read you wrong! if you said: The SDID from a valid signature is the only thing that DKIM provides for TRUST assessment. Then it is correct. But it is not the only thing that DKIM proves and trying to mandate this solve requirement on receivers is completely inappropriate. Now if we wish to be really truly DKIM complete: The AUID MAY be passed to Trust Assessors as well. The ODID MAY be used in advanced identity assessors such as Checking Signing Practices [RFC4686, RFC5595, RFC5016, RFC5617]. -- 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 - proposing ODID Originating Domain Identity
-Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:54 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity The advice that a verifier can ignore the l= tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me. You can't ignore the *tag*. That's the normative change. Whether you ignore the *output* is another matter. But of course you can't ignore the output because l= is internal. Yet another problem. So the issue is that someone might read it as leave l=value out of what you feed to the hash versus hash it, but ignore what it's telling you? If so, I agree, we should fix that. ___ 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: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 04, 2011 11:31 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Now if we wish to be really truly DKIM complete: The AUID MAY be passed to Trust Assessors as well. The ODID MAY be used in advanced identity assessors such as Checking Signing Practices [RFC4686, RFC5595, RFC5016, RFC5617]. It already says: 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. Since the AUID counts as other signature properties and the RFC5322.From counts as result meta-data, can we finally say we're done? (I didn't think so.) ___ 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
Dave CROCKER wrote: On 5/4/2011 9:47 AM, Michael Thomas wrote: The set of people paying attention now are extremely few, and many of them have self-interest in revisiting and/or changing the previous consensus -- taking advantage of the much smaller set of participants. Creative premise. Your assertion is that folks outside the wg are not monitoring it. Given the continuing, intense attention to DKIM that is taking place at a variety of vendues, such as MAAWG and some private industry groups, your assertion does not match the experience a number of us have. Then one has to submit the question: Is the best interest of entire IETF mail community being served using a MAAWG and private industry group mandate to isolate DKIM to single identity trust assessment? I suggest that the best interest of the majority which include small to mid operations, free or commercial is not being served. If you want a solution for DKIM it needs to serve all parties of all sizes and it must not be done at the expense of security. To quote a CEO of one such Marketing company [1]: Are we on the cusp of a customer trust meltdown? I don’t know. But we are dealing with ‘trust’ at a different level than I’ve seen before. Up to now, our trust conversations have centered on whether we can be trusted to use customer data as they’d like it be used. We’ve talked about trust relative to spam, data sharing and the like. These breaches take trust to a much more basic level — can we be trusted to keep our customer data safe and out of the hands of criminals who might do them harm. This is all about data security — something us marketers avoid thinking about, but now must because it has direct brand ramifications. and his recommendation [2]: The framework I see for addressing this challenge is threefold: 1. Rally the industry and articulate data security/best practice guidelines 2. Encourage companies to apply those guidelines within their own environments 3. Provide a collaboration forum for companies to discuss common threats and share best security practices Security can not be ignored and want to give reasons for receivers across the board to accept these new roles, then you must present all outputs to help address all DKIM related evaluations, including does related to security. -- 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 - proposing ODID Originating Domain Identity
On 5/4/2011 11:34 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:54 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity The advice that a verifier can ignore the l= tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me. You can't ignore the *tag*. That's the normative change. Whether you ignore the *output* is another matter. But of course you can't ignore the output because l= is internal. Yet another problem. So the issue is that someone might read it as leave l=value out of what you feed to the hash versus hash it, but ignore what it's telling you? If so, I agree, we should fix that. Seems like the replacement text should be something along the lines of: l= Body length count (plain-text unsigned decimal integer; OPTIONAL, ... Considerations Section 8. To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag. To avoid this attack, signers need to be extremely wary of using this tag, and verifiers might choose to ignore signatures containing it. -- 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
Missing citations for the quotes below: [1] http://www.messagesystems.com/wordpress/?p=65 [2] http://www.messagesystems.com/wordpress/?p=69 Hector Santos wrote: Dave CROCKER wrote: Given the continuing, intense attention to DKIM that is taking place at a variety of vendues, such as MAAWG and some private industry groups, your assertion does not match the experience a number of us have. Then one has to submit the question: Is the best interest of entire IETF mail community being served using a MAAWG and private industry group mandate to isolate DKIM to single identity trust assessment? I suggest that the best interest of the majority which include small to mid operations, free or commercial is not being served. If you want a solution for DKIM it needs to serve all parties of all sizes and it must not be done at the expense of security. To quote a CEO of one such Marketing company [1]: Are we on the cusp of a customer trust meltdown? I don’t know. But we are dealing with ‘trust’ at a different level than I’ve seen before. Up to now, our trust conversations have centered on whether we can be trusted to use customer data as they’d like it be used. We’ve talked about trust relative to spam, data sharing and the like. These breaches take trust to a much more basic level — can we be trusted to keep our customer data safe and out of the hands of criminals who might do them harm. This is all about data security — something us marketers avoid thinking about, but now must because it has direct brand ramifications. and his recommendation [2]: The framework I see for addressing this challenge is threefold: 1. Rally the industry and articulate data security/best practice guidelines 2. Encourage companies to apply those guidelines within their own environments 3. Provide a collaboration forum for companies to discuss common threats and share best security practices Security can not be ignored and want to give reasons for receivers across the board to accept these new roles, then you must present all outputs to help address all DKIM related evaluations, including does related to security. -- 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 - proposing ODID Originating Domain Identity
-Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Wednesday, May 04, 2011 11:54 AM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity You can't ignore the *tag*. That's the normative change. Whether you ignore the *output* is another matter. But of course you can't ignore the output because l= is internal. Yet another problem. So the issue is that someone might read it as leave l=value out of what you feed to the hash versus hash it, but ignore what it's telling you? If so, I agree, we should fix that. Seems like the replacement text should be something along the lines of: l= Body length count (plain-text unsigned decimal integer; OPTIONAL, ... Considerations Section 8. To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag. To avoid this attack, signers need to be extremely wary of using this tag, and verifiers might choose to ignore signatures containing it. +1 As WGLC is closed, we'll have to wait for guidance from Barry about when we could make this change once consensus is reached. ___ 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
Murray S. Kucherawy wrote: Hector wrote: Now if we wish to be really truly DKIM complete: The AUID MAY be passed to Trust Assessors as well. The ODID MAY be used in advanced identity assessors such as Checking Signing Practices [RFC4686, RFC5595, RFC5016, RFC5617]. It already says: 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. Since the AUID counts as other signature properties and the RFC5322.From counts as result meta-data, can we finally say we're done? (I didn't think so.) Professional? :) I can't be any more: Being specific is terrific! Spell it out. Its not a mystery. Its in-scope, not harmful and gives a receiver a better reason to consider DKIM with greater usefulness regarding security which no one should take for granted - even marketers are finally get that point. -- 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 - proposing ODID Originating Domain Identity
On 05/04/2011 11:53 AM, Dave CROCKER wrote: Considerations Section 8. To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag. To avoid this attack, signers need to be extremely wary of using this tag, and verifiers might choose to ignore signatures containing it. Verifiers must not ignore them, assessors on the other hand may. But assessors cannot because the existence of l= is not part of the DKIM output. This results in an inconsistency in the protocol. Mike ___ 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: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 12:08 PM To: dcroc...@bbiw.net Cc: Dave CROCKER; Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Verifiers must not ignore them, assessors on the other hand may. Either could. It's an implementation choice. If the verifier wants to enable the assessor to make the call, it's free to export l= information. ___ 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 5/4/2011 12:08 PM, Murray S. Kucherawy wrote: Verifiers must not ignore them, assessors on the other hand may. Either could. It's an implementation choice. If the verifier wants to enable the assessor to make the call, it's free to export l= information. Verifiers declare a signature as valid or not. This discussion is a very nice example of the difference between protocol vs. implementation. The protocol says l= is valid. However a particular implementor might choose to declare that any l= not covering the entire message shall result in a failed verification. The same applies for verifiers detecting use of sha1. They are free to do that. 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
On 05/04/2011 12:08 PM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 12:08 PM To: dcroc...@bbiw.net Cc: Dave CROCKER; Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Verifiers must not ignore them, assessors on the other hand may. Either could. It's an implementation choice. If the verifier wants to enable the assessor to make the call, it's free to export l= information. I agree that it's an implementation issue. All of this is. But choosing a single output formally makes that a no-no for the assessor, which is a silly outcome. And it's but one silly outcome. What of the h= values? How does an assessor know which ones were signed? That's a layering violation according to -bis. Silly. Mike ___ 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 05/04/2011 11:26 AM, Dave CROCKER wrote: It's because I didn't want to imply that those were the only two. This is quite a remarkable premise for refusing to provide concrete substance. I'm trying to imagine how a working group could ever make progress, were this premise prevalent. Don't offer substance without providing a massive tome to cover everything that qualifies it enough to avoid misunderstanding what hasn't been said... More ad-hominems. I've written a DKIM stack. The first one in fact, followed a week or so later testing with Murray. Call it an argument from authority, but I at least have some experience in what subtle and seemingly inconsequential wording changes can do to implementations. 44 pages of diffs scares the living hell out of me. Mike ___ 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: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Wednesday, May 04, 2011 2:54 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity On 5/4/2011 11:34 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:54 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity The advice that a verifier can ignore the l= tag was in RFC4871, so copying it to RFC4871bis doesn't seem like a problem to me. You can't ignore the *tag*. That's the normative change. Whether you ignore the *output* is another matter. But of course you can't ignore the output because l= is internal. Yet another problem. So the issue is that someone might read it as leave l=value out of what you feed to the hash versus hash it, but ignore what it's telling you? If so, I agree, we should fix that. Seems like the replacement text should be something along the lines of: l= Body length count (plain-text unsigned decimal integer; OPTIONAL, ... Considerations Section 8. To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag. To avoid this attack, signers need to be extremely wary of using this tag, and verifiers might choose to ignore signatures containing it. If this is the sort of advice we are going to give then we should just deprecate l=. Mike ___ 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: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 12:13 PM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; Dave CROCKER; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity I agree that it's an implementation issue. All of this is. But choosing a single output formally makes that a no-no for the assessor, which is a silly outcome. And it's but one silly outcome. What of the h= values? How does an assessor know which ones were signed? That's a layering violation according to -bis. Silly. There's no proscription against providing those details if the verifier wants to export them. The document is saying there is one required output, not only one output; it's a minimum. And I think it's pretty clear about that. ___ 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
Murray S. Kucherawy wrote: I agree that it's an implementation issue. All of this is. But choosing a single output formally makes that a no-no for the assessor, which is a silly outcome. And it's but one silly outcome. What of the h= values? How does an assessor know which ones were signed? That's a layering violation according to -bis. Silly. There's no proscription against providing those details if the verifier wants to export them. The document is saying there is one required output, not only one output; it's a minimum. And I think it's pretty clear about that. But its not clear on the other outputs appropriate for the receiver to consider. You can have a table: status REQUIRED SDIDREQUIRED, MANDATORY for Trust Identity Assessor (see 2.7) AUIDOPTIONAL, see 3.11 ODIDOPTIONAL for Checking Signing Process (see RFC5585) I think what 3.9 should state these minimal DKIM related output purpose is to get a Security and/or Trust Evaluation. -- 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 - proposing ODID Originating Domain Identity
-Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Wednesday, May 04, 2011 1:49 PM To: Murray S. Kucherawy Cc: Michael Thomas; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity But its not clear on the other outputs appropriate for the receiver to consider. And who gets to define appropriate? It's already been pointed out that we could list every current tag's value and a pile of other stuff to pass on to the next layer, which may or may not find it useful, but that would make for an extremely messy protocol. Protocols need to be kept simple. ___ 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
Just a short note. Excuse me for not responding, I've been away from my office for a couple of hours due to the fact that we have today Memorial Day, at which we remember the WW-II victims. I'm catching up reading all contributions... /rolf On 5/4/11 10:57 PM, Murray S. Kucherawy wrote: -Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Wednesday, May 04, 2011 1:49 PM To: Murray S. Kucherawy Cc: Michael Thomas; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity But its not clear on the other outputs appropriate for the receiver to consider. And who gets to define appropriate? It's already been pointed out that we could list every current tag's value and a pile of other stuff to pass on to the next layer, which may or may not find it useful, but that would make for an extremely messy protocol. Protocols need to be kept simple. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ 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 05/04/2011 01:57 PM, Murray S. Kucherawy wrote: And who gets to define appropriate? It's already been pointed out that we could list every current tag's value and a pile of other stuff to pass on to the next layer, which may or may not find it useful, but that would make for an extremely messy protocol. Protocols need to be kept simple. 4871 was simpler yet: it had no notion of an output. It relied on the developer to consider what was appropriate to deliver up the food chain. Manifestly this is very confusing. What is the output of IKE/KINK? Patterned after DKIM, it would be the identity in the cert/ticket. But it is profoundly the wrong question, which is what is leading to all of these non-sequiturs. Mike ___ 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 5/4/2011 12:24 PM, Michael Thomas wrote: On 05/04/2011 11:26 AM, Dave CROCKER wrote: It's because I didn't want to imply that those were the only two. This is quite a remarkable premise for refusing to provide concrete substance. I'm trying to imagine how a working group could ever make progress, were this premise prevalent. Don't offer substance without providing a massive tome to cover everything that qualifies it enough to avoid misunderstanding what hasn't been said... More ad-hominems. Oh? Serious charge. Please cite the specific text that qualifies as an ad hominem. Please explain exactly what about it qualifies as an ad hominem. 44 pages of diffs scares the living hell out of me. What number of pages would make you merely slightly uncomfortable? What is your limit? Does it matter what the nature of the changes is? d/ ps. It's worth noting that an unfounded charge of ad hominem behavior is, itself, an ad hominem, since it focuses attention on a particular person, as well as libeling them... -- 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
On 05/04/2011 02:11 PM, Michael Thomas wrote: On 05/04/2011 01:57 PM, Murray S. Kucherawy wrote: And who gets to define appropriate? It's already been pointed out that we could list every current tag's value and a pile of other stuff to pass on to the next layer, which may or may not find it useful, but that would make for an extremely messy protocol. Protocols need to be kept simple. 4871 was simpler yet: it had no notion of an output. It relied on the developer to consider what was appropriate to deliver up the food chain. I should also expand that this entire situation started with Crocker insisting that we must choose between between i= and d= as The Output. It was a false dilemma then, and it remains a false dilemma. And as with all false dilemmas it only causes heat instead of light. Mike ___ 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
Murray S. Kucherawy wrote: Hector Wrote: But its not clear on the other outputs appropriate for the receiver to consider. And who gets to define appropriate? Well, who gets to define Output Requirements? I will suggest it is both appropriate and required per RFC5585, RFC4686, RFC5017 and RFC5617. It's already been pointed out that we could list every current tag's value and a pile of other stuff to pass on to the next layer, which may or may not find it useful, but that would make for an extremely messy protocol. But that is not being requested. You need to extract all the primary consideration that were discussed, developed, implemented over the years. We have four RFCs, actually seven RFCs thats relates to DKIM rfc4686 Analysis of Threats Motivating DKIM rfc5016 Requirements for a DKIM Signing Practices Protocol rfc5518 Vouch By Reference rfc5585 DKIM Service Architecture rfc5617 DKIM Author Domain Signing Practices (ADSP) rfc5863 DKIM Development, Deployment, and Operations rfc5965 An Extensible Format for Email Feedback Reports But in my opinion RFC5585 is the key document because, well, it has pretty pictures! :) Ideally, you should list all of the above in section 1.1, but that is not being request - just the minimal extracts for receiver security and trust evaluations. Protocols need to be kept simple. and secured and useful without losing your hair extracting this information for all receivers to consider. -- 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 - proposing ODID Originating Domain Identity
On 5/4/2011 2:29 PM, Michael Thomas wrote: I should also expand that this entire situation started with Crocker insisting that we must choose between between i= and d= as The Output. It was a false dilemma then, and it remains a false dilemma. And as with all false dilemmas it only causes heat instead of light. Right. It was all me. Another ad hominem. Nice. But then I suppose the question is why you should have included that explansion. Anyhow, its bad there wasn't any working group consensus on the changes. I guess that means that the published, normative Update RFC was a violation of IETF principles and process. 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
On 05/04/2011 02:32 PM, Dave CROCKER wrote: On 5/4/2011 2:29 PM, Michael Thomas wrote: I should also expand that this entire situation started with Crocker insisting that we must choose between between i= and d= as The Output. It was a false dilemma then, and it remains a false dilemma. And as with all false dilemmas it only causes heat instead of light. Right. It was all me. Another ad hominem. Nice. History is a personal attack? Who knew? But then I suppose the question is why you should have included that explansion. Anyhow, its bad there wasn't any working group consensus on the changes. I guess that means that the published, normative Update RFC was a violation of IETF principles and process. One of the principles of DS is to remove things which aren't implemented or serve no purpose. I think it's quite fitting to ask that DS remove something that was added after the fact in an errata update and has proved to be problematic. Does the implementation report say who has implemented this MUST? If not, why not? Could it be that it's untestable? Mike ___ 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 5/4/2011 2:47 PM, Michael Thomas wrote: On 05/04/2011 02:32 PM, Dave CROCKER wrote: On 5/4/2011 2:29 PM, Michael Thomas wrote: I should also expand that this entire situation started with Crocker ... Right. It was all me. Another ad hominem. Nice. History is a personal attack? Who knew? Ahh. Before using a term -- especially one with social and legal import -- it's worth doing the work of understanding what the term means. As usual, wikipedia is a reasonable reference: http://en.wikipedia.org/wiki/Ad_hominem 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
On 5/4/11 11:32 PM, Dave CROCKER wrote: On 5/4/2011 2:29 PM, Michael Thomas wrote: I should also expand that this entire situation started with Crocker insisting that we must choose between between i= and d= as The Output. It was a false dilemma then, and it remains a false dilemma. And as with all false dilemmas it only causes heat instead of light. Right. It was all me. Another ad hominem. Nice. No, it wasn't Dave. Mea Culpa. I had an off-list discussion with Murray which resulted in http://www.mail-archive.com/ietf-dkim@mipassoc.org/msg15901.html. /rolf ___ 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 05/04/2011 02:53 PM, Dave CROCKER wrote: On 5/4/2011 2:47 PM, Michael Thomas wrote: On 05/04/2011 02:32 PM, Dave CROCKER wrote: On 5/4/2011 2:29 PM, Michael Thomas wrote: I should also expand that this entire situation started with Crocker ... Right. It was all me. Another ad hominem. Nice. History is a personal attack? Who knew? Ahh. Before using a term -- especially one with social and legal import -- it's worth doing the work of understanding what the term means. As usual, wikipedia is a reasonable reference: http://en.wikipedia.org/wiki/Ad_hominem Golly, Dave. I'm trying to figure out how history qualifies as ad hominem. Maybe it's the guilt by association section that has you all riled up? I'd think that you'd be proud that it was your idea. I'm all confused now. Mike PS: I remember very clearly at the interop at Alt-N when you brought this all up. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[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? 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 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? -- Sincerely Hector Santos http://www.santronics.com Dave CROCKER wrote: On 5/4/2011 2:47 PM, Michael Thomas wrote: On 05/04/2011 02:32 PM, Dave CROCKER wrote: On 5/4/2011 2:29 PM, Michael Thomas wrote: I should also expand that this entire situation started with Crocker Right. It was all me. Another ad hominem. Nice. History is a personal attack? Who knew? Ahh. Before using a term -- especially one with social and legal import -- it's worth doing the work of understanding what the term means. As usual, wikipedia is a reasonable reference: http://en.wikipedia.org/wiki/Ad_hominem 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 - 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 - proposing ODID Originating Domain Identity
On 5/4/11 7:48 PM, Dave CROCKER wrote: On 5/4/2011 9:15 AM, Murray S. Kucherawy wrote: My read is that Rolf is objecting to RFC4871bis on the grounds that it conflicts with RFC4686. (He can and should correct me if I'm wrong.) If his concerns would be satisfied by a change (perhaps an appendix?) that simply acknowledges some evolution in thinking based on experience since RFC4686 was published, I imagine that wouldn't meet with much resistance. My reading of the concern is specifically that the statement of DKIM's goal has been refined over time and that all that might be useful for the current document is to cite that fact and, perhaps, compare original versus current statements. The appendix to do that would be very short. It perhaps should cite the incremental changes across the sequence of wg documents and explain the salient meaning of the change, but in informative and not normative terms. If there is more material at issue, what is it? Well, I think you both are right in reading what my concern/objection against 4871bis is. And maybe you're also right in that RFC4871 wasn't that much different of RFC4871bis. I think in the early days of DKIM most people assumed DKIM would become a protocol where: * the body hash and header hash, using various header fields, certifies the DKIM signature and * the DKIM signature certifies the body and header fields, that had been used to create the DKIM signature. The current RFC4871bis defines a protocol where: * the body hash and header hash, using various header fields, certifies the DKIM signature and * the DKIM signature doesn't say anything about the body and header fields, that had been used to create the DKIM signature. Well, if there is /real/ WG consensus that 4871bis is right in this respect, then so be it. But is there real consensus? Or is it just because of what Mike describes as The set of people paying attention now are extremely few. Why don't we see any recent contributions from the authors of RFC4871? (except for Mike then). It seems to me there are a number of WG participants (and I'm one of them), who regret the fact that RFC4871bis does not make the few additional steps required to achieve the expectations of the early days: a protocol that not only provides a DKIM signature (and an important d= payload) but also a protocol that certifies body and (some) header fields. I fail to see why we don't take those one or two extra steps, to make DKIM a protocol with much more use potential. /rolf ___ 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 - proposing ODID Originating Domain Identity
I think in the early days of DKIM most people assumed DKIM would become a protocol where: * the body hash and header hash, using various header fields, certifies the DKIM signature and * the DKIM signature certifies the body and header fields, that had been used to create the DKIM signature. The current RFC4871bis defines a protocol where: * the body hash and header hash, using various header fields, certifies the DKIM signature and * the DKIM signature doesn't say anything about the body and header fields, that had been used to create the DKIM signature. Well, if there is /real/ WG consensus that 4871bis is right in this respect, then so be it. But is there real consensus? Or is it just because of what Mike describes as The set of people paying attention now are extremely few. Why don't we see any recent contributions from the authors of RFC4871? (except for Mike then). Any WG only has the people contributing currently upon which to build consensus. We can't possibly hope to achieve something by requiring votes from past contributors if they've moved on or lost interest. Keep in mind, too, that the document still has to go to the entire IETF and then the IESG for review and evaluation before it gets published. It will get plenty of additional eyes on it to make sure we've done right. It seems to me there are a number of WG participants (and I'm one of them), who regret the fact that RFC4871bis does not make the few additional steps required to achieve the expectations of the early days: a protocol that not only provides a DKIM signature (and an important d= payload) but also a protocol that certifies body and (some) header fields. I fail to see why we don't take those one or two extra steps, to make DKIM a protocol with much more use potential. Suppose we do add a mechanism that allows a signer to make some assertion of the validity of the content of some header field or the body of the message. Won't spammers just make those assertions in an attempt to make you believe something that's untrue? I know I for one would be scared by a message that says This really is a message from eBay. Trust me! unless I have some additional way to verify or trust the claim itself. Signer assertions can't be trusted unless you know for sure you can trust the signer. But DKIM has no way to tell you that. So this is not something DKIM can specify. Thus, I believe we had this debate at length and came to the conclusion that this creates more of a security problem than it solves. Any trust in the validity of the content of a field or the body can certainly be made, but DKIM itself can't do it. So we're back to protocol vs. implementation, and we can't do this in the base protocol, but maybe some higher layer or a later protocol extension could do it. I'd be happy to work on specifying or conducting some experiments if someone has an idea about it; in fact, OpenDKIM already has the hooks needed to do so. ___ 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 - proposing ODID Originating Domain Identity
On 05/04/2011 03:55 PM, Rolf E. Sonneveld wrote: Well, I think you both are right in reading what my concern/objection against 4871bis is. And maybe you're also right in that RFC4871 wasn't that much different of RFC4871bis. I think in the early days of DKIM most people assumed DKIM would become a protocol where: * the body hash and header hash, using various header fields, certifies the DKIM signature and * the DKIM signature certifies the body and header fields, that had been used to create the DKIM signature. Rolf, By certify do you mean assert that they are true/correct/something along those lines? DKIM doesn't make such assertions because there's no way absent a good deal more infrastructure that a receiver should believe such an assertion. The addition of ADSP adds one mechanism that allows a very narrow assertion about From to the author domain be believable, but we certainly do not have anything beyond that. If there was some verbiage in the security analysis, it is likely because the precise delineation of signing protocol (DKIM) and policy protocol (ADSP) was was not completely gelled at the time -- 4686 was put together mainly to get past some process hurdles (imo) to form the wg, so it's pretty early. But even then there was no intent to certify other header fields other than From. Mike ___ 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 5/4/2011 3:04 PM, Michael Thomas wrote: On 5/4/2011 2:29 PM, Michael Thomas wrote: I should also expand that this entire situation started with Crocker ... Right. It was all me. Another ad hominem. Nice. ... As usual, wikipedia is a reasonable reference: http://en.wikipedia.org/wiki/Ad_hominem Golly, Dave. I'm trying to figure out how history qualifies as ad hominem. Started with Crocker points to the person. Simply and directly. Further, you are using the reference as part of a claim that there is a problem with a working group decision. Hence you are attempting to pursue a criticism of that previous working group decision by asserting that it is somehow relevant to note and emphasize who it was that possibly initiated discussion. I really do encourage you to read the definition of ad hominem in wikipedia. Maybe it's the guilt by association section that has you all riled up? That you think it relevant who proposed an idea and that you think it might somehow create guilt is all the essence of ad hominem behavior, all of which repeatedly go very, very far beyond permissible IETF participation behavior. And now that I've supplied an exemplar for explaining and justifying a claim of ad hominem, please note that you have not yet provided your own justification for the claim that you put forward. Will that be forthcoming anytime soon? 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
On 05/04/2011 04:40 PM, Dave CROCKER wrote: [] I'll do Barry the favor of stopping this inane conversation, much as it amuses me. Mike ___ 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 5/4/2011 4:54 PM, Michael Thomas wrote: On 05/04/2011 04:40 PM, Dave CROCKER wrote: I'll do Barry the favor of stopping this inane conversation, much as it amuses me. Michael, You've made a number of serious claims that you have yet to substantiate, including a personal one that otherwise resolves to libel. That's rather more problematic than merely being 'inane'. That you find such behavior amusing should further inform the proper handling of all this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
