[ietf-dkim] Absolving Domain Responsibility
John R. Levine wrote: Putting on my native speaker of American dialect hat, I don't see a useful difference between responsibility and some responsibility in this context. In practice they mean the same thing, and neither means total responsibility. Agreed. If someone goes to the effort of signing a message and publishing a validation key, they have taken some responsibility for the message. On the other hand, if you then complain to them about it, and they tell you to get stuffed, that's the end of it. (You might stop accepting their mail, but that's outside the scope of DKIM.) It's some responsibility, but it may not be very much. So pick one and be done with it. It doesn't matter which one. The issue is that its too vague and incomplete especially when there is an unknown and unrestricted RE-signers involved as part of the framework. What does responsibility actually mean? Does it mean that the last signer is the blame or part of the blame for any harm caused? Does the last signer absolve all previous signer(s) responsibility? Is this something the original domain signer is aware of? INFORMATIVE NOTE: DKIM allows resigners to operate. When a resigning takes place, all previous signer domains no longer have a responsibility for the message. Of course, in a perfect integrated protocol world, one could add statements about POLICY restrictions, but that would be a taboo here at this point. Maybe it can be stated another way to provide the concept of absolving domain responsibility. -- 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] Proposal for new text about multiple header issues
On 01/Nov/10 22:56, Douglas Otis wrote: On 10/30/10 3:05 AM, Alessandro Vesely wrote: On 28/Oct/10 03:36, Douglas Otis wrote: I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Besides RFC 5322 compliance, how is this different from a traditional unsigned spoofed From: accou...@big-bank.com? Having just a signature doesn't mean much, and spelling how to match signature and From field is ADSP's job, even in corner cases. [...] ADSP compliance only requires a valid DKIM signature by the Author Domain, as currently defined by DKIM. This does not protect against pre-pended singleton header fields containing a domain that may have a restricted ADSP assertion, even one that always signs with multiple singleton header fields listed in the h= parameter. If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. Multiple listings of singleton header fields in the h= parameter is an ugly and wasteful hack that offers an incomplete remedy for these selection conflicts. Why ugly hack? You mean from an aesthetic POV? Yes, some bytes are wasted, as usual. Whenever we'll recycle we should fix that. (MIME compliance and UTF-8 header would be valid reasons for v=2, IMHO.) Since it addresses precisely this issue, it is not incomplete in that respect. Note: RFC5322 defines the following singleton header fields: orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, references, and subject. In the example, a domain being targeted by attacks may assert ADSP discardable and sign with the h= parameter listing multiple singleton header fields. A victim might accept information based upon a valid DKIM signature, only to then be misled by different selections used by the display or sort process. DKIM fails to mitigate the exploitation of a DKIM signature inappropriately considered valid when multiple singleton header fields exist. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. Only by ensuring DKIM never asserts a valid signature for messages having multiple singleton header fields, can exploitation of a valid DKIM signature status be avoided. Not quite. Big-isp.com may delegate responsibility for the From field to the relevant author, as it seems common practice. Then, one doesn't even need to infringe RFC 5322 to produce a DKIM-valid bait. For the only by part, unaesthetic signing practices _can_ avoid the singleton exploit. If big-isp.com carefully validates the From field, it should also include it twice in the h= tag. Possibly, one might even derive from there a criterion for guessing what kind of signing practices have been applied. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack.)
On 11/2/10 11:47 AM, Alessandro Vesely wrote: On 01/Nov/10 22:56, Douglas Otis wrote: If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. Per RFC5322 Section 3.6.2, the From header field may contain a comma separated list of mailbox specifications. Section 3 of RFC5617 does not indicate how multiple From header fields are to be handled. This refers to multiple Author Addresses which may exist within a single From header field. Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP. There remains uncertainty as to which From header field might be selected whenever multiple singleton header fields exist. The uncertainty is not resolved by Section 3 of RFC5617, which again presumes RFC5322 compliance. When there is a conflict in DKIM's bottom-up selection process and a typical display or sorting process using top-down, the presumption of RFC5322 compliance creates an easily exploited DKIM security gap! Multiple listings of singleton header fields in the h= parameter is an ugly and wasteful hack that offers an incomplete remedy for these selection conflicts. Why ugly hack? You mean from an aesthetic POV? Yes, some bytes are wasted, as usual. Whenever we'll recycle we should fix that. (MIME compliance and UTF-8 header would be valid reasons for v=2, IMHO.) Since it addresses precisely this issue, it is not incomplete in that respect. This hack does not address the security concern! It incorrectly presumes the valid signature being exploited is that of a high value domain attempting to protect their recipients from a spoofing attack. The valid signature could easily be that of a large domain that is unlikely blocked. Only proactive policies are able to preclude highly polymorphic botnet attacks. Blocking based upon reputation will not be effective in the case of large domains, or in the case of new domains. Note: RFC5322 defines the following singleton header fields: orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, references, and subject. In the example, a domain being targeted by attacks may assert ADSP discardable and sign with the h= parameter listing multiple singleton header fields. A victim might accept information based upon a valid DKIM signature, only to then be misled by different selections used by the display or sort process. DKIM fails to mitigate the exploitation of a DKIM signature inappropriately considered valid when multiple singleton header fields exist. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. Disagree. DKIM verification failed to ensure the presumption of RFC5322 singleton header field compliance. As such, ADSP compliance could be based upon an unseen DKIM signature and an unseen From header field. It would not matter whether high-value domains always include multiple singleton header fields in their h= parameter! Since other domains are unlikely affected by From header field spoofing, why require a practice for every other large domain to use this ugly, wasteful, and ineffective hack? Only by ensuring DKIM never asserts a valid signature for messages having multiple singleton header fields, can exploitation of a valid DKIM signature status be avoided. Not quite. Big-isp.com may delegate responsibility for the From field to the relevant author, as it seems common practice. Then, one doesn't even need to infringe RFC 5322 to produce a DKIM-valid bait. Only by ensuring valid DKIM signatures included a check that there is no multiple singleton header fields, will valid DKIM signature exploitation be mitigated! Only then would deceptive messages be blocked by restrictive ADSP assertions. Currently, one must hope that big-isp.com will not sign a message containing multiple singleton header fields. Even DKIM verification failed to explicitly require there be no multiple singleton header fields before DKIM signatures are considered valid. For the only by part, unaesthetic signing practices _can_ avoid the singleton exploit. If big-isp.com carefully validates the From field, it should also include it twice in the h= tag. Possibly, one might even derive from there a criterion for guessing what kind of signing practices have been applied. Having the h= parameter list multiple singleton header fields will not mitigate the exploit when signed by _different_ domains that have _different_ h= parameters and ADSP assertions. Once there are checks
