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 - 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
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 - 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 - 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
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
Rolf E. Sonneveld wrote: On 5/1/11 6:55 AM, Dave CROCKER wrote: [...] In other words, DKIM has nothing to do with the rfc5321.From field, and therefore it is entirely inappropriate -- that is, out of scope -- for the specification to suggest dealing with it. You mean 5322.From? And how should we read par. 3.2.2 of RFC4686 if it is out of scope for DKIM to deal with it? Although 5322.From is not mentioned here, how can DKIM provide any level of defense against fraudulent use of origin addresses, if d= is the one and only mandatory output of the verification process? Or should we declare this paragraph obsolete? /rolf I think Dave can make it more easier for policy advocates to better understand his statement: DKIM has nothing to do with the rfc5321.From field by explaining it terms of Protocol Consistency using what is already defined in the Requirements for a DKIM Signing Practices Protocol (RFC5017) section 5.3, item #10: 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. Refs: Deployment Consideration, Section 4.3. In short, if there is a Trust Assessment logic at the Verifier and it sees a valid signature signed by a trusted domain, then 1st party policies MUST NOT (according to item #1) apply. No one disputed this. The problems was: 1) Allowing 1st parties to declare it allows 3rd parties to take over, 2) Dealing with anonymous fraudulent abuse streams, Until there is universal trust assessment coverage in greater numbers, verifiers will be dealing with a lot of uncertified or unknown signers. Nonetheless, none of this should exclude the idea of an ODID identity. Its there, it exist, its in the mandatory RFC5311.From and we should allow Local Policies continue to dictate how it will evaluate the blasting of DKIM signed mail on this system. Until SDID can be useful with a payoff, verifiers will need a fall back with 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
On 5/2/11 10:22 PM, Murray S. Kucherawy wrote: -Original Message- From:ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Rolf E. Sonneveld Sent: Monday, May 02, 2011 1:14 PM To:dcroc...@bbiw.net Cc:ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity In other words, DKIM has nothing to do with the rfc5321.From field, and therefore it is entirely inappropriate -- that is, out of scope -- for the specification to suggest dealing with it. You mean 5322.From? Yes, I think that's what he meant. And how should we read par. 3.2.2 of RFC4686 if it is out of scope for DKIM to deal with it? Bad acts related to email-based fraud often, but not always, involve the transmission of messages using specific origin addresses of other entities as part of the fraud scheme. The use of a specific address of origin sometimes contributes to the success of the fraud by helping convince the recipient that the message was actually sent by the alleged author. To the extent that the success of the fraud depends on or is enhanced by the use of a specific origin address, the bad actor may have significant financial motivation and resources to circumvent any measures taken to protect specific addresses from unauthorized use. When signatures are verified by or for the recipient, DKIM _is effective in defending against the fraudulent use of origin addresses_ on signed messages. Although 5322.From is not mentioned here, how can DKIM provide any level of defense against fraudulent use of origin addresses, if d= is the one and only mandatory output of the verification process? 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. So for the consumer it is essential to get, in addition to the d= and the status, the From address that was used to construct the signature. That way the consumer can act upon this triplet of information. Or should we declare this paragraph obsolete? It could stand some revision, I suspect. Nevertheless, the overall threat model doesn't require that DKIM itself, i.e. the protocol being defined, also be the thing that evaluates origin addresses for validity or value. Agreed. It's certainly legitimate to leave that to other modules, just like SMTP isn't required to do any evaluation work of the payload it carries. Agreed. But DKIM is a key component to that overall system. Because DKIM is a key component to the overall system, it must provide reliable information about the origin address to those 'other modules'. If DKIM is not designed to provide that, we'll have to declare par. 3.2.2 of RFC4686 to be 'status: historical'. Question: does DKIM say anything about the 5322.From header value? If we agree with Dave, we'll have to admit that DKIM does not address the threat described in par. 3.2.2 of 4686, do you agree? /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
-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. 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. ___ 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 Sun, 01 May 2011 05:10:06 +0100, Hector Santos hsan...@isdg.net wrote: So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. INFORMATIVE IMPLEMENTATION NOTE: The ODID and SDID are inputs for the optional Checking Signing Practices component as described in the DKIM Service Architecture [RFC5585] +1 -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ 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 01.05.2011 10:38, Hector Santos wrote: Again, its about protocol consistency. So maybe I should ask the chairs for: Consensus needs to be reevaluated IMHO, it needs not: It is premature to define an ODID now. ADSP is considered somewhat broken, and for this message, for example, it seems that the relevant id should be mipassoc.org rather than tana.it. ODID would risk to be a candidate for removal like AUID. From an engineering POV, policy developments are closely related to the verification software, as a matter of facts, so that cleaning up the definition of the interface between them doesn't seem to be urgent. ___ 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 Mon, May 2, 2011 at 11:27 AM, Charles Lindsey c...@clerew.man.ac.uk wrote: On Sun, 01 May 2011 05:10:06 +0100, Hector Santos hsan...@isdg.net wrote: So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. INFORMATIVE IMPLEMENTATION NOTE: The ODID and SDID are inputs for the optional Checking Signing Practices component as described in the DKIM Service Architecture [RFC5585] +1 -1 -- Jeff Macdonald Ayer, MA ___ 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
Alessandro Vesely wrote: On 01.05.2011 10:38, Hector Santos wrote: Again, its about protocol consistency. So maybe I should ask the chairs for: Consensus needs to be reevaluated IMHO, it needs not: It is premature to define an ODID now. ADSP is considered somewhat broken, and for this message, for example, it seems that the relevant id should be mipassoc.org rather than tana.it. ODID would risk to be a candidate for removal like AUID. IMV, ADSP is only broken in that it didn't allow you to declare you were allowing mipassoc.org to sign for you or in general My Mail Is Always Signed - by me or someone else. The only point here is that you did declare an ADSP record (DKIM=UKNOWN) and to get that record, the verifier needs an ODID to be an identity to satisfy the DKIM Service Architecture as described in RFC5585. All the arguable semantics of its value is not the point in the same way regarding the value of SDID. Side Note: Relaxed ADSP policies is a high overhead redundant waste on receivers because the results are indeterminate. This is the same reason why SPF relaxed policies are wasteful too and more domains are changing to a HARD FAIL (-ALL). From an engineering POV, policy developments are closely related to the verification software, as a matter of facts, so that cleaning up the definition of the interface between them doesn't seem to be urgent. Well, sure, current implementations are already supporting AUID and ODID and RFC4871bis doesn't reflect that. Just look at the A-R header recorded by mipassoc.org for your submission signature (that was stripped): Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@tana.it It reported AUID, not the SDID. What makes it all harder is DKIM Mail Integration. We are using the A-R to help with adding DKIM related attribute information to import mail into our backend mail storage. We know what to do because of the 5-6 years of being involved with DKIM. But if a new engineer is looking at RFC4871bis, they are not going to gain from all the current implementations experiences. They will need to read RFC5585 (DKIM Service Architecture) and maybe even RFC5863 (Deployment) and probably at some point ask themselves or their boss ask them about security issues and get that from RFC4686 and what will they see? Something about POLICY called ADSP and then ask, ok, what output from RFC4871bis is needed to support this thing called ADSP. They will find hmmm, there is nothing about it in RFC4871bis. Ok, its the domain in RFC5322.From. All I am saying, lets add that semantic into RFC4871bis and make life easier for the next guy. I guess he will eventually find out at some point and maybe that is what you mean that it isn't urgent. Ok, sure. But we have been so anal with so many other little things, word changes, worried about him not using l= tag or whatever, that we missed out on bigger things he will probably need. Anyway, my opinion. -- 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/1/11 6:55 AM, Dave CROCKER wrote: [...] In other words, DKIM has nothing to do with the rfc5321.From field, and therefore it is entirely inappropriate -- that is, out of scope -- for the specification to suggest dealing with it. You mean 5322.From? And how should we read par. 3.2.2 of RFC4686 if it is out of scope for DKIM to deal with it? Bad acts related to email-based fraud often, but not always, involve the transmission of messages using specific origin addresses of other entities as part of the fraud scheme. The use of a specific address of origin sometimes contributes to the success of the fraud by helping convince the recipient that the message was actually sent by the alleged author. To the extent that the success of the fraud depends on or is enhanced by the use of a specific origin address, the bad actor may have significant financial motivation and resources to circumvent any measures taken to protect specific addresses from unauthorized use. When signatures are verified by or for the recipient, DKIM _is effective in defending against the fraudulent use of origin addresses_ on signed messages. Although 5322.From is not mentioned here, how can DKIM provide any level of defense against fraudulent use of origin addresses, if d= is the one and only mandatory output of the verification process? Or should we declare this paragraph obsolete? /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
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Rolf E. Sonneveld Sent: Monday, May 02, 2011 1:14 PM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity In other words, DKIM has nothing to do with the rfc5321.From field, and therefore it is entirely inappropriate -- that is, out of scope -- for the specification to suggest dealing with it. You mean 5322.From? Yes, I think that's what he meant. And how should we read par. 3.2.2 of RFC4686 if it is out of scope for DKIM to deal with it? Bad acts related to email-based fraud often, but not always, involve the transmission of messages using specific origin addresses of other entities as part of the fraud scheme. The use of a specific address of origin sometimes contributes to the success of the fraud by helping convince the recipient that the message was actually sent by the alleged author. To the extent that the success of the fraud depends on or is enhanced by the use of a specific origin address, the bad actor may have significant financial motivation and resources to circumvent any measures taken to protect specific addresses from unauthorized use. When signatures are verified by or for the recipient, DKIM _is effective in defending against the fraudulent use of origin addresses_ on signed messages. Although 5322.From is not mentioned here, how can DKIM provide any level of defense against fraudulent use of origin addresses, if d= is the one and only mandatory output of the verification process? Why does the output of DKIM need to include something when the consumer of that output already has that information? Or should we declare this paragraph obsolete? It could stand some revision, I suspect. Nevertheless, the overall threat model doesn't require that DKIM itself, i.e. the protocol being defined, also be the thing that evaluates origin addresses for validity or value. It's certainly legitimate to leave that to other modules, just like SMTP isn't required to do any evaluation work of the payload it carries. But DKIM is a key component to that overall system. ___ 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: Although 5322.From is not mentioned here, how can DKIM provide any level of defense against fraudulent use of origin addresses, if d= is the one and only mandatory output of the verification process? Why does the output of DKIM need to include something when the consumer of that output already has that information? Its not really how data is obtained but what Data is needed for ADSP TRUST as described as part of the RFC5585 design. One can reasonably state that the true definition for Output is all INPUT that went into the signature and the result code: HLIST (All the signed headers, h=) SDID (d=) SELECTOR (s=) AUID (i=, if defined) HASH (strength) RCODE (Verifier result code) Its understood the new 3.9 is burning in what is only value required and its for a presumingly a required trust assessor since d= value MUST be passed to it. So why not add a reference to VBR? You have a MUST there to pass to something, help promote VBR to fulfill the MUST. All is that is being asked is cross the tees, dot the eyes for RFC5585 with a MAY for ODID. You don't even have to mention ADSP, just say its an optional part of the total DKIM Service Architecture. Just like VBR is, just like A-R 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
Murray S. Kucherawy wrote: It could stand some revision, I suspect. Nevertheless, the overall threat model doesn't require that DKIM itself, i.e. the protocol being defined, also be the thing that evaluates origin addresses for validity or value. It's certainly legitimate to leave that to other modules, just like SMTP isn't required to do any evaluation work of the payload it carries. But DKIM is a key component to that overall system. A, and the SMTP difference is it did not exclude it in either for any SMTP level values and/or payload: For the client domain, it is a REQUIRE to be valid but not a reason for rejection (due to historical hiccups): For the return path, it is REQUIRE to be valid yet it left the door open. See RFC5321, section 3.3: 3.3 Mail Transactions . Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. For the forwarding path, if you are an open relay or if you have an old computer(s) and can't scale up or out, you just accept it. But more modern systems do local recipient validation checks or just for policy reason 450 Sorry, user p...@public.com, didn't pay his pennies this month! For the Data Payload, the fact you can do a 45x/55x is an explicit specification that for want ever reason you have, it can be temporarily or permanently rejected. RFC2821 learned since RFC821 with an explicit insight for delays in DATA EOD responses in section 6.1 last paragraph To avoid receiving duplicate messages as the result of timeouts, a receiver-SMTP MUST seek to minimize the time required to respond to the final CRLF.CRLF end of data indicator. See RFC 1047 [40] for a discussion of this problem. This is all recognizing the market place increasingly doing payload evaluations to address the highly exploited Accept/Bounce Responsible System requirement. The problem with RFC4871bis is that its locking in a specific assessor with only one mandatory feed. It fails to say: Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the signature may not be determined until ODID (RFC5322.From.Domain value) can be examined. In those cases, the verifier MAY reasonably accept the signature (with a ADSP=PASS status) and then pass the SDID to the Trust Assessor Module. See the difference between the BIS for SMTP vs the BIS for DKIM? 2821 incorporated what was learned other documents since 821. Its hard to extract 4871bis has learned from any of the current experiences document nor ready for 2011+ operations accept only for trust. 2821 nor 5321 does not say anything about any one process output being mandatory as a MUST for a specific any evaluation. But it was all allowed via reply codes just giving way for state machine hooks, shims and extensions and augmented technology - SPF for MAIL FROM and DKIM for the DATA payload. -- 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
Murray S. Kucherawy wrote: -Original Message- But what it did most of for me (yesterday) was highlight the confusion with AUID with the lack of an official DKIM label for an Originating Domain Identity. I guess I was moving forward the past year with integrating DKIM into our mail products and I see now I was mistakenly labeling the AUID as the FROM domain when its not officially defined as the From domain. That's unfortunate, but it's also the first case I've heard of someone mistaking the AUID for the From: field. To be more precise, may erroneous labeling of AUID as the author or user DOMAIN in the From: address for ADSP purposes. Its been an ongoing debate with what AUID (i=) is. Just see the recent threads with Fenton's proposal to remove it and some suggested to keep with refinements like i= should be the From address. This is why Barry's message is important here (got to find it) because if I can correctly recall, he showed both CON and PRO logic on how/why an undefined i= can be assumed to be the From and and the From.domain for ADSP purposes. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. We already have a name for that: RFC5322.From. We don't need a new name for something old. If we want to say From.Domain is an identity, fine by me. I don't see any ambiguity here that needs fixing, unless there are lots of people that want to come forward now and admit they had the same misunderstanding you did. There is plenty of archive evidence old and new regarding i= (AUID) ambiguity, including whether it should be a USER identity as the definition ambiguously says Agent or User. Who/What is an Agent? Undefined? Who is the User? I presume the RFC5322.From? No? -- 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
Dave CROCKER wrote: In other words, DKIM has nothing to do with the rfc5321.From field, and therefore it is entirely inappropriate -- that is, out of scope -- for the specification to suggest dealing with it. At least, please show working group rough consensus support for doing what you suggest. Dave, All I am trying to do is show the inconsistencies in RFC4871bbis not matching current implementation needs and it is incomplete in what RFC5585 describes. I didn't write RFC5585 but if I did, I would not have added the Checking Signing Practice and titled it as DKIM Service Architecture because the concept was removed from DKIM. But you did and the Deployment Guide has an entire section on ADSP. The archive is my evidence, I have stated if you don't want ADSP then don't reference it any DKIM related document. But it was done in in the Deployments Guide and explicitly added as part of the DKIM Service Architecture, not stated it is an Extension or any one shown to be not part of the architecture. Its right there as a large part of the software engineering design. What do you expect people to think? So I suggest reasonable people taking this documents will clearly see policy, signing practice, adsp or whatever you wish to call, its part of the DKIM design and architectural consideration and RFC4871bis does not prepare anyone for that DKIM architecture design. IETF BIS work should be, at least I thought it was, about codifying current implementation and they match RFC5585, not RFC4871bis. Is that a problem? I think so. You seem to think not. All I am saying is with the window of opportunity we have now, connect the dots and be consistent with the RFC described DKIM Service architecture. Finally, you keep saying: DKIM has nothing to do with the rfc5321.From field (Well, I think you meant RFC5322.From. Right?) This is not technically correct. 1) It is the only single requirement for binding to the signature and there again, the archive evidence will show where I have stated on many occasions if we want the above statement to be true, then we need to relax the specs to remove this single mandatory binding signature requirement. 2) The binding of 5322.From is inherently associated with the SDID responsibility claim for the bits that are signed. So for anyone to use SDID trust, it is to both technically and ergonomically (UI) claim the author is trusted whether or not the signer had any association with the author or not. Again, its about protocol consistency. So maybe I should ask the chairs for: Consensus needs to be reevaluated -- 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
Dave CROCKER wrote: On 4/30/2011 9:10 PM, Hector Santos wrote: So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. Oh heck, let's just declare that the DKIM Signing module MAY output anything it wants. That's what 4871 did. Manifestly it worked just fine. We had a tremendous number of interoperable implementations. The procrustean insistence that there be a single output has not helped interoperability one iota. 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 Thomas wrote: Dave CROCKER wrote: On 4/30/2011 9:10 PM, Hector Santos wrote: So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. Oh heck, let's just declare that the DKIM Signing module MAY output anything it wants. That's what 4871 did. Manifestly it worked just fine. We had a tremendous number of interoperable implementations. The procrustean insistence that there be a single output has not helped interoperability one iota. Its just really odd that the we need to hide the facts in RFC4871bis but not in RFC5585 (DKIM Architecture) and RFC5863 (DKIM Deployment Guideline)? Ok, we got it! We need to isolate the signer domain for some future market place. I'm saving my pennies for this. Mission Accomplished. But in the mean time, implementors are not listening. They are looking at other things especially the author thing we must burn into the signature. Why is it so hard to document these facts in the new revised manual? -- 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
Hector Santos wrote: Murray S. Kucherawy wrote: Hector stated: I think this message by Barry in March 2009 summarizing a conference call between Pasi, Stephen and Barry nicely captures the upper/lower layers, ADSP, i= and outputs conflicts that continue today: http://mipassoc.org/pipermail/ietf-dkim/2009q1/011314.html I think that message doesn't say a single thing about layers. It looks entirely procedural to me. Darn it. I copied the wrong link and now I can't find it. :( Let me search again.. Quick search failed. I'll search deeper later if you still want me to. I will find it at some point just to have it in my DKIM notes. Here is the correct message link: Status and direction http://mipassoc.org/pipermail/ietf-dkim/2009q1/011194.html For all and intent and purposes, this message can be reposted today and still bee relevant, covering the final issues we are still dealing with. Note the chairs recommended move forward items, in particular #4 which is what I believe we are trying to help with in this WGLC: 4. *Aim 4871bis at incorporating what we've learned since 4871.* If that results in a document that can and should move to Draft Standard, we'll do that. If it does not, then 4871bis will go to Proposed Standard, and it will take another round of work to move up the standards track. -- 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 4/30/11 10:37 PM, Murray S. Kucherawy wrote: -Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Saturday, April 30, 2011 9:10 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity But what it did most of for me (yesterday) was highlight the confusion with AUID with the lack of an official DKIM label for an Originating Domain Identity. I guess I was moving forward the past year with integrating DKIM into our mail products and I see now I was mistakenly labeling the AUID as the FROM domain when its not officially defined as the From domain. That's unfortunate, but it's also the first case I've heard of someone mistaking the AUID for the From: field. I think this missed Hector's concern. Perhaps it would have been clearer indicating confusion was in respect to i= parameter now called the AUID which can be a copy of an address that was within the From header field. The domain can differ whenever the AUID is a subdomain of the ODID when allowed by the key rr. Section 3.5 had stated the following omitted information: INFORMATIVE DISCUSSION: This document does not require the value of the i= tag to match the identity in any message header fields. This is considered to be a verifier policy issue. Constraints between the value of the i= tag and other identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the i= value and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence reliance on the use of these options should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the i= options. -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
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Sunday, May 01, 2011 4:51 PM To: Michael Thomas Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Its just really odd that the we need to hide the facts in RFC4871bis but not in RFC5585 (DKIM Architecture) and RFC5863 (DKIM Deployment Guideline)? I've lost track of how many times and how many different ways it's been explained that nothing is being hidden. I'm going to give up now. But in the mean time, implementors are not listening. They are looking at other things especially the author thing we must burn into the signature. Which implementers, and why aren't they saying anything? ___ 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: Sunday, May 01, 2011 5:33 PM To: Murray S. Kucherawy Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity Here is the correct message link: Status and direction http://mipassoc.org/pipermail/ietf-dkim/2009q1/011194.html That message (a) was sent six months before ADSP was published, and (b) was written at a time when ADSP still made use of i=. If you take the time to read the text in RFC5617, it doesn't use i= at all. For all and intent and purposes, this message can be reposted today and still bee relevant, ...except that it doesn't cover what the working group actually published. covering the final issues we are still dealing with. Note the chairs recommended move forward items, in particular #4 which is what I believe we are trying to help with in this WGLC: 4. *Aim 4871bis at incorporating what we've learned since 4871.* If that results in a document that can and should move to Draft Standard, we'll do that. If it does not, then 4871bis will go to Proposed Standard, and it will take another round of work to move up the standards track. Sounds like precisely what we've done. ___ 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: -Original Message- Its just really odd that the we need to hide the facts in RFC4871bis but not in RFC5585 (DKIM Architecture) and RFC5863 (DKIM Deployment Guideline)? I've lost track of how many times and how many different ways it's been explained that nothing is being hidden. I'm going to give up now. If nothing is being hidden, then why not explicitly add AUID and ODID (or RFC5585.From.Domain) to the Output Summary? Whats the danger? Maybe its not a Output Summary? Here are some definitions for a summary [1]: A summary, synopsis, or recap is a shorter version of the original. Such a simplification highlights the major points from the much longer subject, such as a text, speech, film, or event. The purpose is to help the audience get the gist in a short period of time. An abstract or a condensed presentation of the substance of a body of material; concise, brief or presented in a condensed form; Performed speedily and without formal ceremony etc. What you are proposing is just the redundant Mandatory Output information, and not a DKIM Output Complete summary that reflects current implementations. But in the mean time, implementors are not listening. They are looking at other things especially the author thing we must burn into the signature. Which implementers, and why aren't they saying anything? Well you, I did and many in the archives has say things, and many have stated very clearly the ODID is considered a very fundamental part of DKIM. RFC5585 reflects how signing practices is part of the expected DKIM Architecture. The two open source APIs: OpenDKIM ALT-N has support for signing practices. Systems using A-R to report DKIM results are using AUID, such as Dave's MLM. And I know our DKIM product has direct support for the design described in RFC5595 including A-R with all four outputs (status, SDID, AUID, ODID) as well as the ADSP extensions. The biggest software company, Microsoft, has announced ADSP support and that means ODID output is required. How can that be not significant? Yes, it is getting tiresome because it is real hard to understand why adding the obvious to the Output Summary is a problem. What harm is there? None that I can see. Why isn't there any mediated compromise to settle these 5-6 years conflict? In my view, your proposed section 1.1 DKIM Architecture Documents and with adding the AUID and ODID as part of the output to make all the documents protocol consistent will settle the issue, in my view, for all parties. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com [1] http://www.google.com/search?rlz=1C1CHMG_enUS291US310q=define:summary ___ 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: -Original Message- Here is the correct message link: Status and direction http://mipassoc.org/pipermail/ietf-dkim/2009q1/011194.html That message (a) was sent six months before ADSP was published, and (b) was written at a time when ADSP still made use of i=. If you take the time to read the text in RFC5617, it doesn't use i= at all. Since day one POLICY anchored off the ODID in the same way Domainkeys, which has inherent support for POLICY, anchored off the ODID. There were suggestions as Barry noted due to the ambiguity (which remains today) for what i= should be and that included i=From and thus possibly it could be the feed for policy. But we also talking the ideas of extension modeling and outputs to pass to them. It was the beginning of reducing it to one only - signer and only for trust purposes, excluding the needs for ADSP. For all intent and purposes, this message can be reposted today and still bee relevant, except that it doesn't cover what the working group actually published. Exactly, which is why we still have the issues today. 4. *Aim 4871bis at incorporating what we've learned since 4871.* If that results in a document that can and should move to Draft Standard, we'll do that. If it does not, then 4871bis will go to Proposed Standard, and it will take another round of work to move up the standards track. Sounds like precisely what we've done. I take the position that 4871bis does not incorporate what we have learned since 4871. If it did, these concerns would not be on-going. -- 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/1/2011 6:36 PM, Murray S. Kucherawy wrote: I've lost track of how many times and how many different ways it's been explained that nothing is being hidden. I'm going to give up now. +1 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/1/2011 6:36 PM, Murray S. Kucherawy wrote: I've lost track of how many times and how many different ways it's been explained that nothing is being hidden. +1 Good. So there should not be a problem *not* hiding an explicit identity definition required to complete the DKIM Service Architecture in RFC5585: 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] If something like this is not added or anything close to it, I don't know any other way it can be described but an intentional neglect to mention anything closely related to it. I would like to ask the chairs if we can get Consensus Reevaluated. From the limited WG participants providing input, it appears we have Rough Consensus for this identity to be included in RFC4871bis. -- 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 4/30/2011 9:10 PM, Hector Santos wrote: So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. Oh heck, let's just declare that the DKIM Signing module MAY output anything it wants. That way we satisfy every possible output desire that has been expressed or might be expressed. After all, it's clear that implementers need the permission. Or we might notice that the purpose of a protocol specification is to define conventions that are followed by both sides of an interaction and that specific specifications are constrained to specific functions, in order to keep them tractable. Telling implementers that they are free to follow any local conventions they want violates both of these otherwise-normal requirements. So rather than continue to fight old, settled issues that primarily have to do with making DKIM try to be something it isn', a better idea would be to review: Section 2.1: INFORMATIVE RATIONALE: The signing identity specified by a DKIM signature is not required to match an address in any particular header field ... Section 4.5, i=: INFORMATIVE DISCUSSION: This specification does not require the value of the i= tag to match the identity in any message header fields. Section 4.10: INFORMATIVE DISCUSSION: This document does not require the value of the SDID or AUID to match an identifier in any other message header field. In other words, DKIM has nothing to do with the rfc5321.From field, and therefore it is entirely inappropriate -- that is, out of scope -- for the specification to suggest dealing with it. At least, please show working group rough consensus support for doing what you suggest. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity
-Original Message- From: Hector Santos [mailto:hsan...@isdg.net] Sent: Saturday, April 30, 2011 9:10 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity But what it did most of for me (yesterday) was highlight the confusion with AUID with the lack of an official DKIM label for an Originating Domain Identity. I guess I was moving forward the past year with integrating DKIM into our mail products and I see now I was mistakenly labeling the AUID as the FROM domain when its not officially defined as the From domain. That's unfortunate, but it's also the first case I've heard of someone mistaking the AUID for the From: field. So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. We already have a name for that: RFC5322.From. We don't need a new name for something old. I don't see any ambiguity here that needs fixing, unless there are lots of people that want to come forward now and admit they had the same misunderstanding you did. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
