On 10/16/10 7:16 AM, Dave CROCKER wrote: > On 10/16/2010 2:39 AM, Mark Delany wrote: > > 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.
Agreed. When used properly, DKIM should be able to offer this assurance. DKIM makes an assessment that neither an MUA or MTA can make. > My point is that DKIM is used within an environment that has a wide > range of attacks, such as including social. While it's of course > fair to say that DKIM "protects" the bits it covers, there are two > lines of potential misunderstanding. > > The first is, of course, the bits not covered. > > The second is that DKIM provides certain kinds of protection, for > the bits it protects, and not others. > > So when we say that DKIM protects some bits, we need to be clear > what it is /not/ doing for those bits and what, associated /other/ > bits are still subject to attack. > > My own observation is that nearly all discussions about DKIM do not > reflect care -- and often don't reflect understanding -- about these > constraints. This leads to overly ambitious expectations for what > DKIM can do. Only DKIM can defend against DKIM exploitations involving elements handled by this protocol. Inadequately defined DKIM specifications, that when implemented, now fail to prevent signatures from mistakenly being considered valid and then exploited. This represents a failure to adequately defined the DKIM process. Informative advice given in Section 6.2 of RFC 4871 was largely limited to ensuring results headers are not spoofed, while DKIM also failed to consider the impact of duplicate header fields that might be relied upon for acceptance, or might be inappropriately selected for display. This issue is not resolved by suggesting a domain being exploited in a spoofed From header field should include double From values in the h parameter :^( DKIM's advice lacked useful specifics in light of discovered exploits of DKIM's poorly defined process. A process where invalid signatures might be considered valid whenever RFC5322 compliance is presumed. Only DKIM is able to correct these errors! Neither the MTA nor the MUA can ensure RFC5322 compliance, nor should they. The MTA's role is a best effort delivery of accepted messages. The MUA role is to display content relevant to users. When DKIM assurance by a domain affects message acceptance by the MTA and/or changes how the message is displayed, then the process creating this assurance MUST also guard against spoofed headers in the same manner as MUAs have been advised with respect to result header fields. It would be wrong to expect MTAs or MUAs to always validate RFC5322 compliance. If there is some other mandatory process offering this protection it should have been included within the DKIM specifications. Please don't suggest RFC5322 compliance assessment is the role of an undefined message filtering process. DKIM should not use that excuse. From: [email protected] From: [email protected] dkim-signature: d=big-isp.com; h=from; ... dkim results: big-isp.com=pass (DKIM should ensure this results in a PERMFAIL) While many may consider DKIM a method to ensure deliverance of bulk email, without an adequately defined DKIM process, senders also run a risk of their users not trusting a process offering bad assurances. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
