Re: [ietf-dkim] Data integrity claims
On Mon, 18 Oct 2010 20:18:16 +0100, Murray S. Kucherawy m...@cloudmark.com wrote: This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. In another message I indicated that I don't presume either, but assert that there's no middle ground; they will or they won't. If they will, informative text is sufficient; if they won't, then we have to start hardening MTAs to defend against MUA attacks because that's where header changes and other enforcements are possible since, by definition, any current annotations are invisible and will stay that way. I'm fine with accepting either model, but we have to understand the implications of picking one. The latter, in particular, involves some major scope creep. No it doesn't. I believe they won't (at least not on any short enough timescale). But we are already in the hardening business, because the basic assumption made by DKIM was that the verification (and resulting action) could and would be done at the boundary layer as part of, or closely associated with, the final MTA, and without any change to existing MUAs. What options for 'action' are available at that point (or were envisaged as being available at that point when DKIM was first written)? I can think of discarding (silently or noisily) increased spamassassin score warning to the end user (e.g. in a changed Subject header) So all we need is to ensure that those same actions will be activated by this new threat; in which case the language to bring this about needs to be just as normative as in the rest of the DKIM specification. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@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] Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Sunday, October 17, 2010 6:23 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Data integrity claims By DKIM process, I would include anything cognizant of DKIM upto but not including the MUA. Mike's secret sauce would count here, eg. Current implementations, especially the two library ones that are referenced most often in here, haven't the functionality to cause header fields to be removed, prefixed, reordered, modified, etc. This change would require them to be overhauled to extend their reach into what the MTA can do. That expansion of scope of DKIM process to me requires a recycle at Proposed Standard. As others have said, there is nothing between DKIM and the MUA that prevent DKIM exploitation so who is going to solve that problem if not us? There's nothing between an MTA and an MUA that prevents this attack in the non-DKIM case at all. Whose place is it to fix that? I can't get my head around how that case is irrelevant here. This is not a new problem, but somehow we're being called upon to deal with it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
-Original Message- From: MH Michael Hammer (5304) [mailto:mham...@ag.com] Sent: Monday, October 18, 2010 11:44 AM To: Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: RE: [ietf-dkim] Data integrity claims There's nothing between an MTA and an MUA that prevents this attack in the non-DKIM case at all. Whose place is it to fix that? I can't get my head around how that case is irrelevant here. This is not a new problem, but somehow we're being called upon to deal with it. The non-DKIM case makes no assertion with regard to authentication (I exclude PGP and S/MIME from the non-DKIM case I think you refer to). If DKIM made no assertion regarding validation of headers + the body length hash then we would almost certainly not be having this discussion in the first place. To the extent that DKIM makes such claims then it is a different case and needs to be considered separately from the non-DKIM case. DKIM doesn't claim the value in From: was valid, only that it was unchanged. If the MUA is DKIM-aware, then it will render the From: field covered by the signature, even though the value that field could be completely bogus. If the MUA is DKIM-ignorant, it renders the first one, for some search order. In neither case is there an assertion of validity of the content. I'm going to go back to the question I asked Wietse... Do we see double headers (one signed and one unsigned one added later) in the normal course of things in the wild? If not then rather than getting into the MUA territory and fixing it, I say let's fix DKIM. If we only see this type of behavior where there is potential non-good activity (I was going to use malicious), we output a warn addition to a pass/fail/none. It's not a huge check to look for the double headers and we aren't boiling the ocean. If we can output a warn bit in addition to pass/fail/none, we're also presuming the MUAs will adapt to consume it. But then the MUAs can just as easily adapt to show you what parts of the message were signed and which were not, and that is in fact the more complete solution. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Monday, October 18, 2010 2:51 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Data integrity claims -Original Message- From: MH Michael Hammer (5304) [mailto:mham...@ag.com] Sent: Monday, October 18, 2010 11:44 AM To: Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: RE: [ietf-dkim] Data integrity claims There's nothing between an MTA and an MUA that prevents this attack in the non-DKIM case at all. Whose place is it to fix that? I can't get my head around how that case is irrelevant here. This is not a new problem, but somehow we're being called upon to deal with it. The non-DKIM case makes no assertion with regard to authentication (I exclude PGP and S/MIME from the non-DKIM case I think you refer to). If DKIM made no assertion regarding validation of headers + the body length hash then we would almost certainly not be having this discussion in the first place. To the extent that DKIM makes such claims then it is a different case and needs to be considered separately from the non-DKIM case. DKIM doesn't claim the value in From: was valid, only that it was unchanged. I said validation, not valid. That is in line with the 4871 text that uses validate or some variation 22 times. That is, what was signed is what was validated on the receiving/verifying side. If the MUA is DKIM-aware, then it will render the From: field covered by the signature, even though the value that field could be completely bogus. If the MUA is DKIM-ignorant, it renders the first one, for some search order. In neither case is there an assertion of validity of the content. See above. This leads me to believe that you might be amenable to informative text rather than normative text. I'm going to go back to the question I asked Wietse... Do we see double headers (one signed and one unsigned one added later) in the normal course of things in the wild? If not then rather than getting into the MUA territory and fixing it, I say let's fix DKIM. If we only see this type of behavior where there is potential non-good activity (I was going to use malicious), we output a warn addition to a pass/fail/none. It's not a huge check to look for the double headers and we aren't boiling the ocean. If we can output a warn bit in addition to pass/fail/none, we're also presuming the MUAs will adapt to consume it. But then the MUAs can just as easily adapt to show you what parts of the message were signed and which were not, and that is in fact the more complete solution. This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. The question is the value equation. I'm not in a position to answer that question. Perhaps we should try to get some of the MUA folks to join the conversation. It may be that some of the well known ones go... hey, never thought about this issue and yeah, we will look into fixing it based on the wider scope. On the other hand they might inquire if we are smoking crack (Just trying to give the two extremes of responses). Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
-Original Message- From: MH Michael Hammer (5304) [mailto:mham...@ag.com] Sent: Monday, October 18, 2010 12:11 PM To: Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: RE: [ietf-dkim] Data integrity claims See above. This leads me to believe that you might be amenable to informative text rather than normative text. Yes, I'm in favour of the most amazing Security Considerations addendum you could ever imagine to cover this, and not in favour of normative text. If we can output a warn bit in addition to pass/fail/none, we're also presuming the MUAs will adapt to consume it. But then the MUAs can just as easily adapt to show you what parts of the message were signed and which were not, and that is in fact the more complete solution. This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. In another message I indicated that I don't presume either, but assert that there's no middle ground; they will or they won't. If they will, informative text is sufficient; if they won't, then we have to start hardening MTAs to defend against MUA attacks because that's where header changes and other enforcements are possible since, by definition, any current annotations are invisible and will stay that way. I'm fine with accepting either model, but we have to understand the implications of picking one. The latter, in particular, involves some major scope creep. Perhaps we should try to get some of the MUA folks to join the conversation. That's a novel idea! I'll poll some other lists I'm on (and you're also on, so you can make sure my wording isn't leading) and see if I can get any feedback. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
I'm trying to find a way for us to build a consensus on how to move forward. While I have tended towards favoring a normative approach, you are swaying me with this amazing Security Considerations addendum. Mike -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Monday, October 18, 2010 3:18 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Data integrity claims -Original Message- From: MH Michael Hammer (5304) [mailto:mham...@ag.com] Sent: Monday, October 18, 2010 12:11 PM To: Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: RE: [ietf-dkim] Data integrity claims See above. This leads me to believe that you might be amenable to informative text rather than normative text. Yes, I'm in favour of the most amazing Security Considerations addendum you could ever imagine to cover this, and not in favour of normative text. If we can output a warn bit in addition to pass/fail/none, we're also presuming the MUAs will adapt to consume it. But then the MUAs can just as easily adapt to show you what parts of the message were signed and which were not, and that is in fact the more complete solution. This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. In another message I indicated that I don't presume either, but assert that there's no middle ground; they will or they won't. If they will, informative text is sufficient; if they won't, then we have to start hardening MTAs to defend against MUA attacks because that's where header changes and other enforcements are possible since, by definition, any current annotations are invisible and will stay that way. I'm fine with accepting either model, but we have to understand the implications of picking one. The latter, in particular, involves some major scope creep. Perhaps we should try to get some of the MUA folks to join the conversation. That's a novel idea! I'll poll some other lists I'm on (and you're also on, so you can make sure my wording isn't leading) and see if I can get any feedback. ___ 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] Data integrity claims
MH Michael Hammer (5304) wrote: This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. The question is the value equation. I'm not in a position to answer that question. Perhaps we should try to get some of the MUA folks to join the conversation. It may be that some of the well known ones go... hey, never thought about this issue and yeah, we will look into fixing it based on the wider scope. On the other hand they might inquire if we are smoking crack (Just trying to give the two extremes of responses). I'm a MUA author of BOTH types and people forget that there are TWO kinds here. We have: Console based Mail Reader/Writers Online Interface (Dialup/Telnet) telnet bbs.wisnerver.com or 305-248-7815 A Frontend Native GUI ONLINE Interface http://www.winserver.com/public/wcnavigator.wct A Frontend Web-based ONLINE Interface http://www.winserver.com (you have to log in) Two QWK, RFC 822/2822/5322 Offline Mail Reader/Writers: http://www.santronics.com/products/olx/index.php http://www.santronics.com/products/sxpress/index.php Two Administrator Report Reader/Writer Online Interfaces http://www.santronics.com/products/pxpress/index.php A Outlook Exchange Component http://www.santronics.com/products/winserver/Exchange.php And very important NNTP (News) and POP3 (Email) Mail Servers to support ALL RFC based Store and forward offline mail reader/writers. All MUAs, including are feed by the backend. It is the BACKEND that feeds the children what it will eat (see). We can ALTER and DO whatever we please to give whatever the ILLUSION we want the MUA to see. This issue is a BACKEND issue whether we want to deal with it at a: MSAAuthenticated Submission (For Local or Remote User/Relay) MDANon-Authenticated Submission to LOCAL USER ONLY or at some DKIM integrated component. To assume that this is should be PUSHED first to MUAs is BAD engineering and NAIVE. But that doesn't mean they don't have to look for it just in case an 3rd party interface software (like an RFC-based mail/writer) whats to make sure that all backends are correct. So as I said in an earlier post, technically, all parts need to deal with this but more so the DKIM API because this is part of their Reason For Living in the first place - mail integrity. Its like a Neighborhood Watch Program vs Real Cops. Everyone will need to deal with it. But the BACKEND is the #1 place to deal with this especially for systems that only have Online Interface devices and/or Legacy Online or Offline mail readers who require (and don't even think about it) that the backend mommy give them clean food to eat - not poison, dirty food. -- 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] Data integrity claims
FWIW, the telnet mail interface typo fix should be: telnet bbs.winserver.com -- HLS Hector Santos wrote: I'm a MUA author of BOTH types and people forget that there are TWO kinds here. We have: Console based Mail Reader/Writers Online Interface (Dialup/Telnet) telnet bbs.wisnerver.com or 305-248-7815 A Frontend Native GUI ONLINE Interface http://www.winserver.com/public/wcnavigator.wct A Frontend Web-based ONLINE Interface http://www.winserver.com (you have to log in) Two QWK, RFC 822/2822/5322 Offline Mail Reader/Writers: http://www.santronics.com/products/olx/index.php http://www.santronics.com/products/sxpress/index.php Two Administrator Report Reader/Writer Online Interfaces http://www.santronics.com/products/pxpress/index.php A Outlook Exchange Component http://www.santronics.com/products/winserver/Exchange.php And very important NNTP (News) and POP3 (Email) Mail Servers to support ALL RFC based Store and forward offline mail reader/writers. All MUAs, including are feed by the backend. It is the BACKEND that feeds the children what it will eat (see). We can ALTER and DO whatever we please to give whatever the ILLUSION we want the MUA to see. This issue is a BACKEND issue whether we want to deal with it at a: MSAAuthenticated Submission (For Local or Remote User/Relay) MDANon-Authenticated Submission to LOCAL USER ONLY or at some DKIM integrated component. To assume that this is should be PUSHED first to MUAs is BAD engineering and NAIVE. But that doesn't mean they don't have to look for it just in case an 3rd party interface software (like an RFC-based mail/writer) whats to make sure that all backends are correct. So as I said in an earlier post, technically, all parts need to deal with this but more so the DKIM API because this is part of their Reason For Living in the first place - mail integrity. Its like a Neighborhood Watch Program vs Real Cops. Everyone will need to deal with it. But the BACKEND is the #1 place to deal with this especially for systems that only have Online Interface devices and/or Legacy Online or Offline mail readers who require (and don't even think about it) that the backend mommy give them clean food to eat - not poison, dirty food. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On 10/18/10 12:18 PM, Murray S. Kucherawy wrote: This is no more presumptuous than expecting that MUAs will adapt to consume the output of DKIM as it stands now. In another message I indicated that I don't presume either, but assert that there's no middle ground; they will or they won't. If they will, informative text is sufficient; if they won't, then we have to start hardening MTAs to defend against MUA attacks because that's where header changes and other enforcements are possible since, by definition, any current annotations are invisible and will stay that way. I'm fine with accepting either model, but we have to understand the implications of picking one. The latter, in particular, involves some major scope creep. Should the charter of a security related protocol need to anticipate minor modifications to a verification process, that appears essential for ensuring a DKIM signature is not inappropriately associated with an incorrect From header field? Rather than expecting changes to a plethora of consumers of DKIM results, which might be used for sorting or display, ensuring PERMFAIL occurs whenever replicate From header fields are detected ensures DKIM will not be complicit in deceiving consumers of its results. Adding such a check represents a normative change to DKIM, since it can not be just advisory warnings to DKIM's consumers that suggests when DKIM results should be ignored. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent: Monday, October 18, 2010 3:33 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Data integrity claims Should the charter of a security related protocol need to anticipate minor modifications to a verification process, that appears essential for ensuring a DKIM signature is not inappropriately associated with an incorrect From header field? Any effort, security or otherwise, needs to scope itself correctly. We, for very good reasons, chartered ourselves originally to come up with a system that requires minimal infrastructure changes. I claim that inserting an Authentication-Results field is minimal, as it is incremental. But if we also claim MUAs and users pretty much ignore that, which is the case today, then it (or any solution that is strictly an annotation of some kind) fails to have the protective impact you're seeking. The only option then is to obstruct delivery in some way, and that is not incremental and thus not minimal, and certainly pushes the boundaries of our charter (e.g. [1]). Rather than expecting changes to a plethora of consumers of DKIM results, which might be used for sorting or display, ensuring PERMFAIL occurs whenever replicate From header fields are detected ensures DKIM will not be complicit in deceiving consumers of its results. This, again, fails to deliver on your stated goal since the PERMFAIL result is almost completely invisible. On the other hand, if you claim MUAs will adapt to DKIM to show what parts of a message were covered by a validated signature, then we don't really need to provide any normative requirements because MUAs have already figured out what they need to do. [1] http://tools.ietf.org/wg/dkim/charters?item=charter-dkim-2006-07-03.txt ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On 10/18/10 4:15 PM, Murray S. Kucherawy wrote: On Monday, October 18, 2010 3:33 PM, Douglas Otis wrote: Should the charter of a security related protocol need to anticipate minor modifications to a verification process, that appears essential for ensuring a DKIM signature is not inappropriately associated with an incorrect From header field? Any effort, security or otherwise, needs to scope itself correctly. We, for very good reasons, chartered ourselves originally to come up with a system that requires minimal infrastructure changes. I claim that inserting an Authentication-Results field is minimal, as it is incremental. But if we also claim MUAs and users pretty much ignore that, which is the case today, then it (or any solution that is strictly an annotation of some kind) fails to have the protective impact you're seeking. The only option then is to obstruct delivery in some way, and that is not incremental and thus not minimal, and certainly pushes the boundaries of our charter (e.g. [1]). Ensuring an inappropriate DKIM PASS result is not conveyed through _any_ results mechanism when there are multiple From header fields is the _only_ means able to deal with not knowing how the information will be used. For DKIM to play a role, it must affect how a message is handled, and/or how it is displayed. There is no way to know which. In either case, returning a DKIM PASS when there are multiple From header fields represents a result that is easily exploited. Since multiple From header fields violate RFC5322, there should not be a problem in having DKIM require a MUST return PERMFAIL in such a case. There is little to justify even checking the validity of the signature for multiple From header fields. Advice indicating these messages should be refused seems wholly appropriate, but this might conflict with a desire to leave interpretations of DKIM results be defined by a policy layer that specifies appropriate actions. Rather than expecting changes to a plethora of consumers of DKIM results, which might be used for sorting or display, ensuring PERMFAIL occurs whenever replicate From header fields are detected ensures DKIM will not be complicit in deceiving consumers of its results. This, again, fails to deliver on your stated goal since the PERMFAIL result is almost completely invisible. On the other hand, if you claim MUAs will adapt to DKIM to show what parts of a message were covered by a validated signature, then we don't really need to provide any normative requirements because MUAs have already figured out what they need to do. An MUA is only one of many different DKIM results consumers. The MUA may highlight a From header field when signed by an Author Domain, or annotate the domain offering a valid DKIM signature. Either way, ensuring the DKIM result is PERMFAIL is the only sure method to ensure exploitation is thwarted. Are you suggesting DKIM should advise consumers about when PASS should be ignored, and about critical checks that were skipped? This of course would be due to DKIM's lack of format compliance checking of elements bound to the signature. I too am willing to support Jim's text as being a reasonable alternative to kicking the can down the road. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On 10/15/10 4:50 PM, Murray S. Kucherawy wrote: On Friday, October 15, 2010 2:30 PM, Douglas Otis wrote: Citing a layer violation makes little sense. With DKIM, the message body does not stand on its own. DKIM binds elements related to the RFC5322 header fields with the message body, for the purpose of extending favorable message handling, such as white-listing. Since DKIM has this property, citing layer violations lacks any basis. I thought the What DKIM does thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more. That makes this assertion inapposite. I think perhaps now would be a good time to make that explicit, since a lot of people (including some in here) are continuing to infer that DKIM should be used to protect the body. So I propose this be added to 4871bis: 1.4 Data Integrity A DKIM signature associates the d= name with the computed hash of some or all of the message (see Section 3.7) in order to prevent the re-use of the signature with different messages. Verifying the signature asserts that the hashed content has not changed since it was signed, and asserts nothing else about protecting the end-to-end integrity of the message. DKIM mandates inclusion of the From header field and recommends validating DKIM signatures related to this field first. Why? DKIM failed to include fundamental aspects of RFC5322 compliance, that when not followed, permits the exploitation of message handling on the basis of mistaken DKIM PASS results when there are multiple From header fields, for example. The verification process MUST explicitly disqualify such messages from ever receiving a PASS verification. RFC5322 compliance is neither an assured function of SMTP nor MUAs. As such, DKIM has a serious process flaw when verification fails to ensure normally singular headers have not been pre-pended. Their display or assumed relationship with a DKIM PASS may enable methods to exploit either what is displayed or associated with DKIM results. Clearly, Section 6.2 was short sighted in the advice given. I apologize in advance if that causes yet another traffic maelstrom, but it's something we need to settle. And since the discontinuous expectation of DKIM exists outside the working group as well as inside it, that means consensus needs to be codified. Not being explicit with respect to important aspects of RFC5322 compliance in the DKIM verification process represents an error that can be remedied ONLY by changing the DKIM verification process. A few minor changes to this process would ensure these types of exploits are thwarted. If or when some other exploit is discovered, the process may need further adjustment. There is an expectation in the integrity of the DKIM process. Few security related protocols don't require adjustments to mitigate various types of newly discovered exploitations. Isn't this why specifications aren't advanced until there is greater confidence in the integrity of the process? Systems discovered having defective capacitors should be recalled and have the defective devices replaced. Toys for children removing fingers should be recalled and modified. Otherwise, manufacturers risk a class action suit. There is no reason not to repair DKIM when its verification process fails to offer the expected protections being sought. Please, don't blame the short-comings on the MUA. John and Mark are right. It is wrong to consider the DKIM signature some type of academic exercise devoid of how DKIM might be exploited. The WG should step up and deal with this assumed compliance vulnerability. Without DKIM, this vulnerability would not exist. Can someone name a current MUA that treats a DKIM-signed, malformed message differently from an unsigned one in terms of what it renders? If not, that last assertion is also false. And if the response to that is MUAs can change to show what was validated and what wasn't, then they can also change to handle the malformations we're talking about. And, in fact, that's probably easier to implement. There are millions of MUAs that are unlikely to be updated anytime soon. Even so, the error clearly rests with the DKIM verification process. Why not fix the problem without requiring all MUAs to change, where non-compliance with RFC5322 only becomes a problem in conjunction with message handling and displays based upon DKIM results. Had the DKIM verification results not been in error, there would not be a problem. Don't think of DKIM as being inviolate offering only a disjointed sacrosanct identifier. DKIM process must also guard against the exploitation of its results, with goes back the first question asked. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Saturday, October 16, 2010 2:39 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Data integrity claims On Sat, Oct 16, 2010 at 12:10:48AM -0400, Dave CROCKER allegedly wrote: On 10/15/2010 8:32 PM, Mark Delany wrote: Therefore one could argue that DKIM is protecting that relationship between the message and identifier. Clever phrasing. Might be too subtle for general use, but I think it offers a perspective that could be useful. I think the issue here is that when people talk about protecting a message, they tend to have in mind all sorts of attacks designed to trick users. DKIM actually does not have much to say about such things. Yes, it ties an identifier to a bag of bits, and yes it specifies what those bits are, but it really does deal only with those bits and not (necessarily) the entire message. I have a problem with this approach and I don't pretend to know the right answer. My problem is that if some valuable domain like paypal sends me a bunch of bits that I or my MUA or my MTA ties to paypal.com then the end goal of DKIM is, IMO, that those bunch of bits I see are the ones that paypal sent. No more, no less. To murder another idiom: What you see is what they sent is I believe the ultimate goal of DKIM. Or, what you complain about is what they sent. Whatever. So anything that circumvents what you see is what they sent I think is in scope for DKIM to eliminate or mitigate. Is that requirement solved in the verification protocol of DKIM or is that solved in advice to MTAs/MUAs? I don't know. But I am sure that if we don't end up with that guarantee, then I do wonder what we are offering. Mark is more clearly articulating what I have been struggling with. This is also one of the reasons I have always felt that 1st party signatures are inherently a different value proposition from 3rd party signatures. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On 10/16/2010 1:07 PM, MH Michael Hammer (5304) wrote: This is disingenuous on your part. It is akin to saying that although the common usage of hammers is to hit nails, we must accept within the definition of normal the usage of beating people on the head with a hammer simply because some people do and it is not documented through warnings on hammers that this is not normal. There is a subset of headers that the vast majority of informed (even semi-informed) implementers would agree on. Perhaps we need to reach a consensus and document this to protect the children. Wow. From sophistry to disingenuous. Today seems to be when people think that tossing in slams at motives, legitimacy and style somehow facilitates discussion. It invites all sorts of responses in kind, none of which would be constructive. And I've tossed in this comment merely to note how irritating today's vocabulary choices are and suggest folks make more judicious choices. My postings have constructive intent and serious thought behind them. The might be wrong, but they are not naive, frivolous, poorly intentioned, or any of the other things that permit superficial dismissal. Please debate them on substance; if you've missed the substance, please show the courtesy of simply asking for clarification. In any event, it's clear that at least two of you have entirely missed my point. So let's try this again, more carefully: There is a fundamental difference between saying something bad might happen versus do this specific thing to provide this specific protection. One is a generic warning. The other is a spec. The difference is not subtle. Re-read my questions. They werequite precise. The text in the spec does not provide precise answers; when it appears to provide precise answers, they were not the result of informed thought: Which header fields are essential to protect? How much of the message body is essential to protect? Let me emphasize: Most of the advice in the spec is not useful, except as basic reminders to an already-knowledgeable reader. Useful means that someone who does not already knows the answer is able to figure out the answer from the guidance that is given or the guidance tells them how to go about finding out the answer. They can't do that with what is in the spec. I don't mean we should rip out all the advice, merely that we need to distinguish between soft advice and serious, technical specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent: Friday, October 15, 2010 2:30 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Citing a layer violation makes little sense. With DKIM, the message body does not stand on its own. DKIM binds elements related to the RFC5322 header fields with the message body, for the purpose of extending favorable message handling, such as white-listing. Since DKIM has this property, citing layer violations lacks any basis. I thought the What DKIM does thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more. That makes this assertion inapposite. I think perhaps now would be a good time to make that explicit, since a lot of people (including some in here) are continuing to infer that DKIM should be used to protect the body. So I propose this be added to 4871bis: 1.4 Data Integrity A DKIM signature associates the d= name with the computed hash of some or all of the message (see Section 3.7) in order to prevent the re-use of the signature with different messages. Verifying the signature asserts that the hashed content has not changed since it was signed, and asserts nothing else about protecting the end-to-end integrity of the message. I apologize in advance if that causes yet another traffic maelstrom, but it's something we need to settle. And since the discontinuous expectation of DKIM exists outside the working group as well as inside it, that means consensus needs to be codified. John and Mark are right. It is wrong to consider the DKIM signature some type of academic exercise devoid of how DKIM might be exploited. The WG should step up and deal with this assumed compliance vulnerability. Without DKIM, this vulnerability would not exist. Can someone name a current MUA that treats a DKIM-signed, malformed message differently from an unsigned one in terms of what it renders? If not, that last assertion is also false. And if the response to that is MUAs can change to show what was validated and what wasn't, then they can also change to handle the malformations we're talking about. And, in fact, that's probably easier to implement. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
On Friday, October 15, 2010 07:50:36 pm Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Douglas Otis Sent: Friday, October 15, 2010 2:30 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] detecting header mutations after signing Citing a layer violation makes little sense. With DKIM, the message body does not stand on its own. DKIM binds elements related to the RFC5322 header fields with the message body, for the purpose of extending favorable message handling, such as white-listing. Since DKIM has this property, citing layer violations lacks any basis. I thought the What DKIM does thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more. That makes this assertion inapposite. Does it? If the identifier is bound to the hashed information, I think it makes complete sense to believe one can make something of that content and it's relation to the identifier. It provides a stable identifier, but that identifier is inextricably tied to the signed content. I think perhaps now would be a good time to make that explicit, since a lot of people (including some in here) are continuing to infer that DKIM should be used to protect the body. So I propose this be added to 4871bis: 1.4 Data Integrity A DKIM signature associates the d= name with the computed hash of some or all of the message (see Section 3.7) in order to prevent the re-use of the signature with different messages. Verifying the signature asserts that the hashed content has not changed since it was signed, and asserts nothing else about protecting the end-to-end integrity of the message. I apologize in advance if that causes yet another traffic maelstrom, but it's something we need to settle. And since the discontinuous expectation of DKIM exists outside the working group as well as inside it, that means consensus needs to be codified. Your proposed wording sounds a lot to me like what I think of as protecting the end-to-end content. I feel there's a lot of talking past each other here. If we were doing what you think of as protecting, what would be different? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Friday, October 15, 2010 5:09 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Data integrity claims I thought the What DKIM does thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more. That makes this assertion inapposite. Does it? If the identifier is bound to the hashed information, I think it makes complete sense to believe one can make something of that content and it's relation to the identifier. It provides a stable identifier, but that identifier is inextricably tied to the signed content. There might be a better way to characterize it, but I think the answer comes from the errata RFC upon which we reached consensus a while back: The primary payload delivered by a DKIM validation is the validated domain name. Reputation, for example, would be checked against that, and not against the body hash or some other part of the message. The claim that it binds elements related to the RFC5322 header fields with the message body is the means of the algorithm, not the end. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
I thought the What DKIM does thing was a long-dead horse, as we'd long ago reached consensus that what DKIM does is provide a stable identifier on the message, and nothing more. That makes this assertion inapposite. I think perhaps now would be a good time to make that explicit, since a lot of people (including some in here) are continuing to infer that DKIM should be used to protect the body. So I propose this be added to 4871bis: (I don't know what inapposite is, but I like it!) To your point, the identifier and the message must go together to be meaningful. One without the other is meaningless. Therefore one could argue that DKIM is protecting that relationship between the message and identifier. Or put another way, if a DKIM signer is taking responsibility for the message, then DKIM should also protect the original assertion of the signer - which again includes the message as well as the identifier. I don't think you can disconnect the two and retain value. Maybe that's what folk mean when they say protect the body? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Data integrity claims
Murray S. Kucherawy wrote: There might be a better way to characterize it, but I think the answer comes from the errata RFC upon which we reached consensus a while back: The primary payload delivered by a DKIM validation is the validated domain name. Reputation, for example, would be checked against that, and not against the body hash or some other part of the message. That does not exclude any other functionalities. The claim that it binds elements related to the RFC5322 header fields with the message body is the means of the algorithm, not the end. But the associations are still binding. They are direct associations, especially 5322.FROM hence why author policy is still of interest for the framework (and a WG work product). I think these discussions get a little lost of how applications should be applied. The out of scope Reputation Application is just one of them, but it is not the only one. We got policy to work out at some point and thats a WG item. I posted this a while back but you will have input of various kinds for the various evaluators: DKIM_RESULT= DKIM_VERIFY(MSG) REP_RESULT = DKIM_REPUTATION(DKIM_RESULT, DKIM.D) POLICY_RESULT = DKIM_POLICY(DKIM_RESULT, MSG.FROM, DKIM.D) But these are not the only ones. You will see Expert System like designs take place or systems with flexible rule based scripting available to allow for local policy to be molded. For example, an expert rule can be: if a signature fails and has TESTING flag enabled, then see if he stilling testing after __12__ months then if so, negative classify this signer domain. I indicated a long time ago that we be careful with t=y flag and add guidelines track the usage. It was added. Note, I think the focus with signer domain is fine for trust but it must be recognize that there are other associations and efforts to minimize it, I don't think will be well accepted to the layman market place. Most will see what they see and DKIM signatures are passive extra information. All I like to distinguish is that attempting to only extract the valid signer domain as good useful information must be mirrored with its faults. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
