Re: [ietf-dkim] Issue: Section 3.9 - Add AUID and ODID
On 5/5/11 1:52 AM, Hector Santos wrote: Murray wrote: You want AUID and RFC5322.From added to the Output Requirements section explicitly. BTW, while RFC5322.From will satisfy requirements, I am proposing a new ODID identity (RFC5322.From.domain) since that is whats already extracted by APIs in order to do the current ADSP support. I proposes the following: 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. INFORMATIVE IMPLEMENTATION NOTE: The ODID and SDID are inputs for the optional Checking Signing Practices component as described in the DKIM Service Architecture [RFC5585] 3.9. Output Requirements For each signature that verifies successfully or produces a TEMPFAIL result, the output of a DKIM verifier module MUST include the set of: o The domain name, taken from the d= signature tag; and o The result of the verification attempt for that signature. | Optional output are: | | o The Agent or User Identity (AUID) taken from i=, if any. | | o The Originating Domain Identity (ODID). Verifier output | MAY consider ODID when no signatures or invalid signatures | are found. The output MAY include other signature properties or result meta- data, including PERMFAILed or otherwise ignored signatures, for use by modules that consume those results. See Section 6.1 for discussion of signature validation result codes. are you aware of the fact that 5322.From can consist of a mailbox-list as per section 3.6.2 of RFC5322? What is the ODID in case the 5322.From contains multiple 'mailboxes' (terminology of RFC5322)?. /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: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] Protocol layering / Software vs. Protocol
On 5/4/11 10:01 AM, Dave CROCKER wrote: Folks, \ In terms of working group process, one line of criticism demands re-opening (and, apparently, reversing) the work of the Update (RFC 5672). I haven't seen any working group consensus to do this nor any industry feedback indicating this is necessary. Consequently, attempts to pursue the content of that work is entirely out of scope for the current working group effort. There are two continuing threads of other, technical dissatisfaction being expressed that are based on fundamental misunderstandings of protocol design concepts. The discussion on Wikipedia looks pretty good, for background: http://en.wikipedia.org/wiki/Network_protocol#A_basis_for_protocol_design The easy misunderstanding is about the basic difference between software design and protocol design. When a discussion is about a protocol specification, reference to the vagaries of software implementers' choices means that the discussion is no longer about the protocol. A protocol is a contract between two or more sides of an exchange. The contract needs to be extremely precise so that all sides know exactly what is required and what is meant. This includes semantics, syntax, and rules of exchange. Semantics means all of the meaning, not just the meaning of individual fields. And it means inputs and outputs. DKIM is unable to _only_ consider signature confirmation and not also expect existing email agents to not also adopt DKIM's unusual header selection methods retro-actively. To be compatible with existing email infrastructure and transparent to the fullest extent possible, one can not expect new supporting infrastructure or modified clients; This can *only* be achieved by some mandatory test within the Verifier. -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 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
[ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID Originating Domain Identity
On 04.05.2011 21:13, MH Michael Hammer (5304) wrote: boun...@mipassoc.org] On Behalf Of Dave CROCKER On 5/4/2011 11:34 AM, Murray S. Kucherawy wrote: 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: 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. I thought we meant ignore the value that this tag provides; that is, fail signatures only if the body length actually changed. W.r.t. RFC 4871, we only removed the text suggesting to remove text that appears after the specified content length (assuming it grew). So we have a very poor wording in both documents, pining for arguments among opposite-minded implementers, one claiming that another is non-compliant. If this is the sort of advice we are going to give then we should just deprecate l=. +1: it was an error in the PS and the DS fixes it. Alternatively we can allow it, warn, and expect implementers to code heuristics that can discern attacks from regular footers. We can't have both. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID Originating Domain Identity
Alternatively we can allow it, warn, and expect implementers to code heuristics that can discern attacks from regular footers. Speaking as an implementer, I ignore l=, because the hassle of working around it and trying to guess how hostile any added content might be is vastly greater than any utility it has. As I've often noted, there are about a hundred ways that a mailing list can break a signature, and l= deals (badly) with only one of them. 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 - Keep your Eye on the Prize!
Murray, your technical *subjective* reasoning is not convincing. First, as for procedural issues, I have come to understand for bis work, how Hansen, Klensin and SM describes it. You do not seem to reflect the same advice and quite often in contradiction. In regards to AUID, the only technical *non-subjective protocol recommendation to consider is the one in section 3.11: Upon successfully verifying the signature, a receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present. It provides the non-subjective protocol technical justifications for both outputs to be part of the output requirements. Nothing else need to be said. Its called Software Engineering. Choosing not to include it is a subjective implementation reason. In regards to ODID, its a fundamental message header. Its technical history and importance should not be something to be explained. In DKIM, that fundamental messaging entity is reflected as the only single header requirement for signature binding and per RFC5585, RFC4686, RFC5017 and RFC5617 an essential part for security. Most important of all: DKIM can not mandate which is now a highly questionable protocol with highly subjective information in it with an highly isolated mandate for a mandatory single output with a MUST have requirement for a Trust Identity Assessor without *explicitly exposing* all the minimal outputs, especially when the default design excludes security protocol design considerations. Protocol implementation is whats it all about and for RFC4871bis, it is for specific implementation design only. If we want to exclude specific implementations, the Output Requirements needs to be more open with DKIM Complete information for receivers to better consider. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 04, 2011 4:22 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize! You want AUID and RFC5322.From added to the Output Requirements section explicitly. At least two other participants disagree on either technical or procedural grounds. 1) I have not seen any no arguments based on technical merits, or one that didn't have an substantial proof. Purely procedural and even SM showed your opinion on procedural (for BIS work) was not quite IETF correct. You're not reading our replies then. So here we go again, once more for the record, one of each: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. Moreover, the suggestion conflates protocol and implementation; you can already pass the AUID, the From: field, or any other value you want to an adjacent layer or module without requiring a change to the current wording of 3.9. The fact that some adjacent modules want or need it is not proscribed by the current wording either, so the proposed change is actually unnecessary. Procedural: Working group consensus to date has been to list only SDID as the required output, along with a status (see RFC5672, and RFC4871bis WGLC traffic). Adding a value to the list of outputs is in contradiction to the Draft Standards advancement process (see BCP9, Section 4.1.2). Only removing things is allowed. SM didn't correct my interpretation of BCP9, but rather highlighted another aspect of it. What he said and what I said are both correct. 2) There are at least four others (including myself) who agree with the ODID proposal of both variable or one of them. I've only seen one other that supports the RFC5322.From as being a mandatory output. So let's tackle that now too, for the record: Technical: The RFC5322.From is an unvetted value. The entire field could be garbage. It's inappropriate; see above, same reasons. Procedural: Adding a value, see above, same reasons. So what's the compromise? Your ball. You are the editor of the documents. Its up to you to reduce the conflicts with proposed compromising text. Murray, I am not your problem as much you believe, insist it is. I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, especially Section 5.3 which explains the role of the document editor. Contrary to what you seem to believe, it is not our job to find a way to slip your suggestion in to the document just because it is repeated often. Rather, a change to a standards track document, which RFC4871 and RFC5672 are, requires working group consensus and then similarly consensus
Re: [ietf-dkim] Issue: Section 3.9 - Add AUID and ODID
Rolf E. Sonneveld wrote: 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. INFORMATIVE IMPLEMENTATION NOTE: The ODID and SDID are inputs for the optional Checking Signing Practices component as described in the DKIM Service Architecture [RFC5585] 3.9. Output Requirements For each signature that verifies successfully or produces a TEMPFAIL result, the output of a DKIM verifier module MUST include the set of: o The domain name, taken from the d= signature tag; and o The result of the verification attempt for that signature. | Optional output are: | | o The Agent or User Identity (AUID) taken from i=, if any. | | o The Originating Domain Identity (ODID). Verifier output | MAY consider ODID when no signatures or invalid signatures | are found. The output MAY include other signature properties or result meta- data, including PERMFAILed or otherwise ignored signatures, for use by modules that consume those results. See Section 6.1 for discussion of signature validation result codes. are you aware of the fact that 5322.From can consist of a mailbox-list as per section 3.6.2 of RFC5322? What is the ODID in case the 5322.From contains multiple 'mailboxes' (terminology of RFC5322)?. While technically possible, it is rare (more on this below). It was worked out over the years to be either the first address or each one is to be considered. SSP described it as a potential DNS overhead and this is where the first one was considered technically correct and for its rarity factor. Also limits can be placed. I believe the consensus (as reflected in ADSP) was to leave it technically open leaving it up to the implementation ADSP [RFC5617] has the following: 3. Operation Overview .. If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. This document does not address the process a host might use to combine the lookup results. But keep in mind of the importance of End to End technical vetting process beginning predominately at the Originating point. I have design, nor seen an MUA in my 29 years of mail system commercial product development, which allows for multi-address From INPUT. That is for good reason - mail hosting 99.99% of the time force only one From tied to the user account And the exception is normally a system that allow for manual From change such as in an anonymous mail system - but its still only one. One that allows for uncontrolled multi-address From Input is already a BAD SYSTEM. So the ODID payoff is just to consider the first address. I'm open though to pass the RFC5322.From value and the only reason I didn't suggest that is because it passes additional technical subjective semantics such as user part considerations and all we wanted here as a ADSP functionality. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Murray, your technical *subjective* reasoning is not convincing. First, as for procedural issues, I have come to understand for bis work, how Hansen, Klensin and SM describes it. You do not seem to reflect the same advice and quite often in contradiction. In regards to AUID, the only technical *non-subjective protocol recommendation to consider is the one in section 3.11: Upon successfully verifying the signature, a receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present. It provides the non-subjective protocol technical justifications for both outputs to be part of the output requirements. Nothing else need to be said. Its called Software Engineering. Choosing not to include it is a subjective implementation reason. In regards to ODID, its a fundamental message header. Its technical history and importance should not be something to be explained. In DKIM, that fundamental messaging entity is reflected as the only single header requirement for signature binding and per RFC5585, RFC4686, RFC5017 and RFC5617 an essential part for security. Most important of all: DKIM can not mandate which is now a highly questionable protocol with highly subjective information in it with an highly isolated mandate for a mandatory single output with a MUST have requirement for a Trust Identity Assessor without *explicitly exposing* all the minimal outputs, especially when the default design excludes security protocol design considerations. Protocol implementation is whats it all about and for RFC4871bis, it is for specific implementation design only. If we want to exclude specific implementations, the Output Requirements needs to be more open with DKIM Complete information for receivers to better consider. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Hector Santos Sent: Wednesday, May 04, 2011 4:22 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize! You want AUID and RFC5322.From added to the Output Requirements section explicitly. At least two other participants disagree on either technical or procedural grounds. 1) I have not seen any no arguments based on technical merits, or one that didn't have an substantial proof. Purely procedural and even SM showed your opinion on procedural (for BIS work) was not quite IETF correct. You're not reading our replies then. So here we go again, once more for the record, one of each: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. Moreover, the suggestion conflates protocol and implementation; you can already pass the AUID, the From: field, or any other value you want to an adjacent layer or module without requiring a change to the current wording of 3.9. The fact that some adjacent modules want or need it is not proscribed by the current wording either, so the proposed change is actually unnecessary. Procedural: Working group consensus to date has been to list only SDID as the required output, along with a status (see RFC5672, and RFC4871bis WGLC traffic). Adding a value to the list of outputs is in contradiction to the Draft Standards advancement process (see BCP9, Section 4.1.2). Only removing things is allowed. SM didn't correct my interpretation of BCP9, but rather highlighted another aspect of it. What he said and what I said are both correct. 2) There are at least four others (including myself) who agree with the ODID proposal of both variable or one of them. I've only seen one other that supports the RFC5322.From as being a mandatory output. So let's tackle that now too, for the record: Technical: The RFC5322.From is an unvetted value. The entire field could be garbage. It's inappropriate; see above, same reasons. Procedural: Adding a value, see above, same reasons. So what's the compromise? Your ball. You are the editor of the documents. Its up to you to reduce the conflicts with proposed compromising text. Murray, I am not your problem as much you believe, insist it is. I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, especially Section 5.3 which explains the role of the document editor. Contrary to what you seem to believe, it is not our job to find a way to slip your suggestion in to the document just because it is repeated often. Rather, a change to a standards track document, which RFC4871 and RFC5672 are, requires working group consensus and then similarly consensus up the chain of
Re: [ietf-dkim] Issue: Section 3.9 - Add AUID and ODID
Rolf E. Sonneveld wrote: 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity MAY be considered as an output communicated to an advanced Identity Assessor module. INFORMATIVE IMPLEMENTATION NOTE: The ODID and SDID are inputs for the optional Checking Signing Practices component as described in the DKIM Service Architecture [RFC5585] 3.9. Output Requirements For each signature that verifies successfully or produces a TEMPFAIL result, the output of a DKIM verifier module MUST include the set of: o The domain name, taken from the d= signature tag; and o The result of the verification attempt for that signature. | Optional output are: | | o The Agent or User Identity (AUID) taken from i=, if any. | | o The Originating Domain Identity (ODID). Verifier output | MAY consider ODID when no signatures or invalid signatures | are found. The output MAY include other signature properties or result meta- data, including PERMFAILed or otherwise ignored signatures, for use by modules that consume those results. See Section 6.1 for discussion of signature validation result codes. are you aware of the fact that 5322.From can consist of a mailbox-list as per section 3.6.2 of RFC5322? What is the ODID in case the 5322.From contains multiple 'mailboxes' (terminology of RFC5322)?. While technically possible, it is rare (more on this below). It was worked out over the years to be either the first address or each one is to be considered. SSP described it as a potential DNS overhead its and this is where the first one was considered technically correct and for its rarity factor. Also limits can be placed. I believe the consensus (as reflected in ADSP) was to leave it technically open leaving it up to the implementation ADSP [RFC5617] has the following: 3. Operation Overview .. If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. This document does not address the process a host might use to combine the lookup results. But keep in mind of the importance of End to End technical vetting process beginning predominately at the Originating point. I have design, nor seen an MUA in my 29 years of mail system commercial product development, which allows for multi-address From INPUT. That is for good reason - mail hosting 99.99% of the time force only one From tied to the user account And the exception is normally a system that allow for manual From change such as in an anonymous mail system - but its still only one. One that allows for uncontrolled multi-address From Input is already a BAD SYSTEM. So the ODID payoff is just to consider the first address. I'm open though to pass the RFC5322.From value and the only reason I didn't suggest that is because it passes additional technical subjective semantics such as user part considerations and all we wanted here as a ADSP functionality. -- 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] Issue: Section 3.9 - Add AUID and ODID
Rolf E. Sonneveld wrote: On 5/5/11 1:52 AM, Hector Santos wrote: 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] are you aware of the fact that 5322.From can consist of a mailbox-list as per section 3.6.2 of RFC5322? What is the ODID in case the 5322.From contains multiple 'mailboxes' (terminology of RFC5322)?. A follow up, in section 2.3, it has among Identity examples: - author - author's organization If we wanted to be 100% Ideally RFC5322 correct, it should be - author or authors - an author's organization Although it would be technically correct, I don't think it would be practically realistic to view or operate it in that way. That is why the focus is really on a single author and its organization. The one point I want to make, related to what another person considered the unvetted concept behind the originating author, in the history of BBS and mail hosting software, the user account is unique. Depending on the brand, the communicated From is generally offered based on the type of mail conference provided (or where he is posting mail). Overall, the user namespace can contain identities such as: real name login identity alias name email address For example if the mail type is related to: Networking - Mail.from = user.name|user.alias|user.alias RFC5322.From = user.email Local- Mail.from = user.name|user.alias|user.alias But it really depends on the host, for example you mail see in the UI (User Interface) when starting a new message that supports anonymity: From: default name (o) Use default (_) Use Alias (_) Use Anonymous (if enabled) Using anonymous is really rare and the history of using began with servicing the Daddy Market (Porn or Adult Mail) market. What was important is that it wasn't tied to the user account like alias would be. Not the say it wasn't locally logged and traceable, that depended on how much the mail host wanted to provide user anonymity. Of course, the spam problem started when we began networking mail hosting systems. So along with the good aspects, came the potentially bad. But excluding the bad for a moment, it become of a disjoint problem - in other words, the social personal community which was predominately local, now was distributed. In simple terms, Joe was known in system ABC, but when networking started, Joe was not known in system XYZ. We increasingly use an email id to login as well, but its all tied to vetted set of user identities. Technically, the From wasn't required to be identity for responses, as long as there was a Networking Address. However, very importantly, it is the From that end users generally see. So from a networking standpoint, there is technical explanation why the From can be viewed as unvetted. But that is where DKIM comes in: DKIM still applies because the primary technical transport design presumption is end to end mail integrity and authenticity. The point is; regardless of that the original value of the from, it is expected NOT to be altered. ADSP is just about whether DKIM applies or not, but whether failure to authenticate is an important author's organization policy. Its not about the From can be unvetted even though the idea of vetting can be also be part of making sure the original message integrity is intact using DKIM. It also comes a policy presumption that the Original From was vetted at the originating domain organization. Whether you can TRUST the message *context* and/or who wrote it is the 2nd party of the DKIM equation. That is why we still need some sort of 3rd party trusted vouching feature as the final DKIM evaluation for the user sake. For the mail host, the TOS (Term of Service) would essentially be: We will DKIM authenticate the message and we will also look at certain trusted signers to give you TRUST indicator. You may not know who or be associated with the author or even who is the trusted signer is, but if you TRUST US, then the message is not considered BAD. Whether that POLICY or MINDSET holds, it is something the senders, especially Spammers, Marketers what the receiver to convey to users if DKIM is the technology or basis to do this. So its all really up to the receiver market and my posting of late is 100% a engineering reflection that focusing on a single TRUST factor only is seriously insufficient for receivers to consider solely. The problem with the DMA vendors is that they believe that all mail should be
Re: [ietf-dkim] Output considered harmful
Mike Thomas says... 4871 had it right on this account. Everything since then has screwed the pooch. Put it back. Mike, I have a lot of catching up to do, having been travelling for a bit. Some of that catching up involves dealing with complaints (plural) about what you say on this list. While I'm catching up and figuring out how to handle all this, there's one thing I can directly say up front: Stop talking like this on the list. Be professional and polite. Avoid rancor. Don't say things that people are likely to take as implying that they're stupid, or have done stupid things. That stuff, along with phrases like screwed the pooch, doesn't make your point more effectively or forcefully; rather the opposite: it makes people tend to ignore your underlying point because of the resentment you're creating. And it prompts them to complain to me. Be civil, even if you're angry. And if someone else irks you, don't escalate it; stay civil then, too. And this all goes for everyone, of course, though here I'm specifically saying it to Mike. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output requirements
+ Verifiers SHOULD ignore those signatures that produce a PERMFAIL + result (see Section 7.1), acting as though they were not present in + the message. ... s/Verifiers SHOULD ignore/Identity assessors SHOULD ignore/ (and probably in other places too). Veriffiers are explicitly instructed to return PERMFAIL/TEMPFAIL), and returning something is evidently inconsistent with ignoring it. +1 Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Protocol layering / Software vs. Protocol
Dave says... In terms of working group process, one line of criticism demands re-opening (and, apparently, reversing) the work of the Update (RFC 5672). I haven't seen any working group consensus to do this nor any industry feedback indicating this is necessary. Consequently, attempts to pursue the content of that work is entirely out of scope for the current working group effort. I'll point out that Dave is offering his *opinion* about whether this is in or out of scope. I'll provide the chair's judgment on that, as the one who has the task of determining scope: it's out of scope. We had this discussion back when we did 5672, and got rough consensus on it. Not unanimity, but rough consensus. We're not going over that again. 4871bis is, and should be a merging of 4871 and 5672. Barry, as chair Doug says... This can *only* be achieved by some mandatory test within the Verifier. Not at all; that's exactly Dave's point in discussing the difference between the protocol and the software system that wraps around it. The Verifier is a component that verifies the signature, and that's all we're defining normatively here. Other parts of the system will evaluate things whether the verified signature can be relied upon, and what it can be relied upon for; whether the domain that signed it is trustworthy; whether a failed signature can nonetheless provide useful information; and so on. It's reasonable to give non-normative advice, perhaps strong advice, about what other system components might do in that regard. Most of that advice should be in the other, informational documents, and some might even reasonably be here (and some of it is). But it can't be mandatory. I'll point out what Paul Hoffman had said many times in earlier discussions: you can't control what the receiver [meaning the overall system on the verification side] will do... you can only give it the information. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, and it can't be false either. I don't even know what false means in this context. It's just a value which is guaranteed to be within the to the d= domain's bailiwick. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] issue: Section 2.6/ 3.5 AUID/i= should have pubkey t=s info
I think the definition of i= should include information about the public key t=s tag. This t=s information that will deviate the i= definition is not found until 3.6.1 and 3.10. The same can apply to section 2.6 Agent or User Identifier (AUID) which makes no mention of t=s or any reference to section 3.6.1, 3.10. Possible small change in 3.5 i= definition, 2nd paragraph change: The syntax is a standard email address where the Local-part MAY be omitted. The domain part of the address MUST be the same as, or a subdomain of, the value of the d= tag. If the public key contains t=s, then the domain part of the address MUST match the value of d= tag. Possible small change in 2.6: 2.6. Agent or User Identifier (AUID) A single identifier that refers to the agent or user on behalf of whom the Signing Domain Identifier (SDID) has taken responsibility. The AUID comprises a domain name and an optional Local-part. The domain name is the same as that used for the SDID or is a sub-domain of it. If the public key contains t=s, then the domain name MUST be the same as SDID. For DKIM processing, These certainly aren't necessary, but I think they add clarity, so I support adding the sentence in each place (after fixing the grammar). While we're at it, we should change sub-domain in that 2.6 paragraph to subdomain, to be consistent with usage in the rest of the document (the only place sub-domain is used is in the ABNF, where it has to be). Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Question: ADSP DKIM=UNKNOWN and A-R reporting
That's not what RFC5617 says. Meaning: No valid Author Domain Signature was found on the message and the published ADSP was unknown. Can't that be read as meaning a non-Author Domain Signature was not expected. No, not at all. I can't think of any interpretation of that sentence that would give that meaning. No valid Author Domain Signature was found says nothing about anything else that might or might not have been found. If it rains, then I won't play baseball, says nothing about what I'll do if it doesn't rain. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID Originating Domain Identity
If this is the sort of advice we are going to give then we should just deprecate l=. +1: it was an error in the PS and the DS fixes it. Alternatively we can allow it, warn, and expect implementers to code heuristics that can discern attacks from regular footers. Speaking as an implementer, I ignore l=, because the hassle of working around it and trying to guess how hostile any added content might be is vastly greater than any utility it has. As I've often noted, there are about a hundred ways that a mailing list can break a signature, and l= deals (badly) with only one of them. I agree, as a participant. Nevertheless, we have consensus to leave it in because of the stats Murray gave us on the usage (on the signing side). We certainly could deprecate it, and add something that says that verifiers MAY consider a signature for which l= is less than the full message length to fail verification. Such a change should have been proposed earlier in the process, but I won't consider it out of scope if we have consensus to do that now. And, of course, we can always add non-normative advice somewhere (but I suggest NOT in 4871bis) that evaluation systems that use DKIM should check l= against the message length when deciding what to do. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] issue: Section 2.6/ 3.5 AUID/i= should have pubkey t=s info
On 5/5/2011 1:37 PM, Barry Leiba wrote: Possible small change in 3.5 i= definition, 2nd paragraph change: The syntax is a standard email address where the Local-part MAY be omitted. The domain part of the address MUST be the same as, or a subdomain of, the value of the d= tag. If the public key contains t=s, then the domain part of the address MUST match the value of d= tag. Repeating or rephrasing specification text invites divergent interpretations. If folks believe that it is important to create a linkage between the two segments of text, then make the reference be linkage, not repetition. So, for example: Note the constraint on the value of i= that is imposed by the t=s tag of the stored key record. (See Section 3.6.1). Possible small change in 2.6: 2.6. Agent or User Identifier (AUID) A single identifier that refers to the agent or user on behalf of whom the Signing Domain Identifier (SDID) has taken responsibility. The AUID comprises a domain name and an optionalLocal-part. The domain name is the same as that used for the SDID or is a sub-domain of it. If the public key contains t=s, then the domain name MUST be the same as SDID. For DKIM processing, See above. 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] Protocol layering / Software vs. Protocol
On 5/5/11 1:24 PM, Barry Leiba wrote: Dave says... In terms of working group process, one line of criticism demands re-opening (and, apparently, reversing) the work of the Update (RFC 5672). I haven't seen any working group consensus to do this nor any industry feedback indicating this is necessary. Consequently, attempts to pursue the content of that work is entirely out of scope for the current working group effort. I'll point out that Dave is offering his *opinion* about whether this is in or out of scope. I'll provide the chair's judgment on that, as the one who has the task of determining scope: it's out of scope. We had this discussion back when we did 5672, and got rough consensus on it. Not unanimity, but rough consensus. We're not going over that again. 4871bis is, and should be a merging of 4871 and 5672. Barry, as chair Doug says... This can *only* be achieved by some mandatory test within the Verifier. Not at all; that's exactly Dave's point in discussing the difference between the protocol and the software system that wraps around it. The Verifier is a component that verifies the signature, and that's all we're defining normatively here. Other parts of the system will evaluate things whether the verified signature can be relied upon, and what it can be relied upon for; whether the domain that signed it is trustworthy; whether a failed signature can nonetheless provide useful information; and so on. Providing unreliable assurance is worse than none. DKIM can not expect other agents, especially those predating DKIM, that when message acceptance is based upon DKIM PASS from trusted domains that they must also be aware of bad assumptions made by DKIM. As it currently stands, DKIM offers PASS for highly deceptive messages having invalid formats. A narrow view about what entails a DKIM verified message *MUST* include what is needed to safely employ its output by subsequent agents. Not considering likely deceptive forms of a message represents a _truly_ dangerous specification. The current DKIM introduction states the following: 1. is compatible with the existing email infrastructure and transparent to the fullest extent possible; 2. requires minimal new infrastructure; 3. can be implemented independently of clients in order to reduce deployment time; 4. can be deployed incrementally; 5. allows delegation of signing to third parties. This view expressed as: Other parts of the system will evaluate things whether the verified signature can be relied upon, and what it can be relied upon for; whether the domain that signed it is trustworthy; whether a failed signature can nonetheless provide useful information; and so on. is clearly at odds with points 1, 2, 3, and 4 when this also entails re-evaluation of message elements already examined by DKIM. It's reasonable to give non-normative advice, perhaps strong advice, about what other system components might do in that regard. Most of that advice should be in the other, informational documents, and some might even reasonably be here (and some of it is). But it can't be mandatory. For DKIM to be trustworthy and not cause greater harm, it MUST confirm the form of the message is valid. A much simpler task than public key cryptography easily done simultaneously. It would be negligent and unreasonable to blame the transport for multiple From header fields when there are more than one, or their order, or which will be used by subsequent agents. Why is it reasonable to expect other protocols will repair DKIM's oversights and bad assumptions? Responsibly respond to exploits as they are discovered irrespective of the specification's status. I'll point out what Paul Hoffman had said many times in earlier discussions: you can't control what the receiver [meaning the overall system on the verification side] will do... you can only give it the information. There is no argument with Paul's statement. Nevertheless, don't excuse the deceptive nature of bad advice offered by DKIM verification process when it overlooks both invalid and likely highly deceptive messages. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
On 5/5/11 1:34 PM, Michael Thomas wrote: On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, and it can't be false either. I don't even know what false means in this context. It's just a value which is guaranteed to be within the to the d= domain's bailiwick. Agreed. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] issue: Section 2.6/ 3.5 AUID/i= should have pubkey t=s info
Repeating or rephrasing specification text invites divergent interpretations. Indeed, and I agree that not repeating is best. On the other hand, we're already repeating the part about or a subdomain of, which is why I support adding a notation about except when t=s. Note the constraint on the value of i= that is imposed by the t=s tag of the stored key record. (See Section 3.6.1). That works for me. Barry, as participant ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID Originating Domain Identity
I agree, as a participant. Nevertheless, we have consensus to leave it in because of the stats Murray gave us on the usage (on the signing side). I agree we need to leave it in, but as I said, I would rather not offer advice about how to code around its limitations, not least because whatever advice we offer will be insufficient. 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] Question: ADSP DKIM=UNKNOWN and A-R reporting
Barry Leiba wrote: That's not what RFC5617 says. � �Meaning: �No valid Author Domain Signature was found on the message � � � � � � �and the published ADSP was unknown. Can't that be read as meaning a non-Author Domain Signature was not expected? No, not at all. I can't think of any interpretation of that sentence that would give that meaning. No valid Author Domain Signature was found says nothing about anything else that might or might not have been found. If it rains, then I won't play baseball, says nothing about what I'll do if it doesn't rain. This is part of the semantics clarification we seek. You are probably catching up, but the text descriptions for DKIM=UNKNOWN are found in ADSP Section 4.2.1 and 5.4: unknown The domain might sign some or all email. Meaning: No valid Author Domain Signature was found on the message and the published ADSP was unknown. Think of the software: First, No ADSP record is found. In this case, there is absolutely no policy semantics regarding DKIM the verifier can make for the author domain. No sig, double, triple, mixed 1st, 3rd, some valid, some broken, whatever, the verifier can not make any ADSP interpretation other than dkim-adsp=none. But now we have an explicit DKIM=UNKNOWN; The semantic and also part of the WG conflicts is the absence of a valid Author Domain signature and includes the presence of a valid 3rd party signature. In other words, should the verifier? #1 - ignore signatures where SDID != ODID, and #2 - only look for signatures where SDID == ODID The problem Barry, and this was a long term issue with ADSP, is that it lacks an explicit semantic or definition where it says: mail can be signed by anyone or ignore mail that have 3rd party signatures This conflict begins in RFC5017 (Requirements for Signing Practice) in most debated item in section 5.3, Item #10: 5.3. Practice and Expectation Requirements 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. Base on this, its implies to me we should ignore 3rd party signatures, but that is conflicts with ADSP and even the fundamental idea behind RFC5017 - check for author policies and policy violations. So I can understand that if there are no explicit record, then the receiver can not make any presumptions about the signatures in the message. But if there is a record, then its negates what item 10# is saying for the verifier with a local policy to support ADSP to mind its bee's wax with the presence of a non-first party signature. Do you see the conflict? Just consider when an explicit ADSP record is found with: DKIM=DISCARDABLE DKIM=ALL Does these also come an item #10 ignore 3rd party signature concept even with the receiver is willing to honor ADSP and author domain policies? -- 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] issue: Section 2.6/ 3.5 AUID/i= should have pubkey t=s info
Barry Leiba wrote: I think the definition of i= should include information about the public key t=s tag. �This t=s information that will deviate the i= definition is not found until 3.6.1 and 3.10. �The same can apply to section 2.6 Agent or User Identifier (AUID) which makes no mention of t=s or any reference to section 3.6.1, 3.10. Possible small change in 3.5 i= definition, 2nd paragraph change: � � � The syntax is a standard email address where the Local-part MAY be � � � omitted. �The domain part of the address MUST be the same as, or a � � � subdomain of, the value of the d= tag. �If the public key � � � contains t=s, then the domain part of the address MUST match � � � the value of d= tag. Possible small change in 2.6: � �2.6. �Agent or User Identifier (AUID) � �A single identifier that refers to the agent or user on behalf of � �whom the Signing Domain Identifier (SDID) has taken responsibility. � �The AUID comprises a domain name and an optional Local-part. �The � �domain name is the same as that used for the SDID or is a sub-domain � �of it. If the public key contains t=s, then the domain name MUST � �be the same as SDID. For DKIM processing, These certainly aren't necessary, but I think they add clarity, so I support adding the sentence in each place (after fixing the grammar). While we're at it, we should change sub-domain in that 2.6 paragraph to subdomain, to be consistent with usage in the rest of the document (the only place sub-domain is used is in the ABNF, where it has to be). Barry, as participant Yes, I had pointed out either text or a reference to 3.6.1. This document is filled with scattered information and section 3.5 will be used a quick reference summary of the tags. So I think i= should have this important t=s policy record exception highlighted some way. They need to know if their implementations allows for the subdomain form to be inputted, that the public key management needs to tied to it. So if my software has: Signer: Selector: Optional Agent or User Identity: _ when they press SAVE, I have to decide what to do, like Popop Warning box: Warning, the Public Key for this signer/selector must has a t=s tag Continue to Save: Yes | 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 - Keep your Eye on the Prize!
-Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Thursday, May 05, 2011 1:35 PM To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize! On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated. I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, and it can't be false either. I don't even know what false means in this context. It's just a value which is guaranteed to be within the to the d= domain's bailiwick. By garbage, I mean not guaranteed to have any useful meaning. Think of how it might be used by someone seeking to avoid accumulating negative reputation. The subdomain might not exist; it could be a string of random (though syntactically legal) characters. The local part might not have anything at all to do with an email address or other login ID that's valid on the signer or author systems, and may be unique per-message meaning it can't be used as input to an assessor in a useful way. So, I believe, it's essentially meaningless as far as the protocol can stipulate. Assertions of its semantics thus fall outside of the base DKIM spec. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, and it can't be false either. Perhaps the word stable would be more applicable. The d= value is tied to the DNS, is relatively stable, and the verifier can check that there's a key record in the DNS that matches the signature. The parts of the i= beyond what's in the d= are just an assertion by the signer with no semantics, verifiable or otherwise, and are no more useful than any other unverified assertion. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
Dave CROCKER wrote: I don't think this is correct. The signer creates and signs the i= value, so it's not garbage, By garbage, I mean not guaranteed to have any useful meaning. So, I believe, it's essentially meaningless as far as the protocol can stipulate. Assertions of its semantics thus fall outside of the base DKIM spec. It's worth noting that Murray said 'could be'. But Murray's final paragraph has the essential points: within the scope of the DKIM Signing specification, the receive-side has no way to determine what the semantics of i= are, as we discussed at great length when formulating the Update RFC. But, then, folks on the list already know that. We have here is a failure to communicate. - Cool Hand Luke Dave, This approach you have is an implementation conclusion. It is not part of the protocol. The protocol clearly says in 3.11: Upon successfully verifying the signature, a receive-side DKIM verifier MUST communicate the Signing Domain Identifier (d=) to a consuming Identity Assessor module and MAY communicate the Agent or User Identifier (i=) if present. Therefore with no subjective consideration, no assertions, no philosophies, the protocol defines a process model of: trust = TrustIdentityAssessor(SDID [,AUID]) There is NO opinion about this! That is your DKIM Trust Protocol Model with a Mandatory SDID input and an optional AUID input. In order for this to work, your 3.9 Output Requirement MUST expose those two parameters at the very least. There is no assertions or opinions - thats the protocol you defined. Now, when you begin to exclude it, then you mixing up implementation desires with subjective conclusion that really is not part of the protocol defined. There is some subjective information notes about the value, but that has nothing to do with the protocol you defined. To be consistent you have three protocol design tech writing choices: 1) Remove the second clause in that 3.11 3rd paragraph - problem fixed. 2) Add AUID to 3.9 as an optional output 3) Remove section 3.9 This is what happens when you add something in the last minute without any consensus. It was just added - no consensus. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
