On 02/Nov/10 22:58, Douglas Otis wrote: > 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.
50% agreed. This mistake is only in DKIM, IMHO. > 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! RFC 5616 actually just says "multiple Author Addresses". It does not say that having examined a single From field is sufficient. Although, that is an apparently legitimate inference --if one assumes RFC 5322 compliance-- software that acts that way can still be considered buggy. >>> Multiple listings of singleton header fields in the h= parameter > > 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. It does not presume that. The hack just allows signers to protect from this exploit /if they care/. In order to protect against illicit usage of a domain name by third parties one could use ADSP. > 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. You mean the receiving host has a "whitelist_from_dkim" clause? Yes, in that case the message probably passes even if it fails ADSP. How is this a DKIM error? It has been repeatedly noted that DKIM allows producing poor signatures, and whitelisting signers with such practices is a questionable setting. Nevertheless, it works. >> 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. Here you hypothesize that the ADSP verifier is unable to see all the From fields in the message. That makes this an implementation issue. Tough verifiers see all author addresses. > 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? Because it protects from this specific attack. A domain does not set h=from:from to protect against abuse of its domain name: It sets it in order to protect its signatures from being spoofed. > Admitting a mistake and including explicit checks for multiple > singleton header fields in the DKIM verification process properly > handles the greater concern. This proper repair will reduce > multiple listings of singleton header fields to being an interim > solution for an unlikely exploit. IMHO, it is not the proper solution. It changes the design of DKIM so as to include heuristic considerations about RFC 5322 compliance that are not pristine to digital signatures. That would result in fuzzy results and more false positives. I note that the 95% "pass" shown in http://www.opendkim.org/stats/report.html#mlm_comparison is so low that nobody would discard a message because of an invalid signature. For DKIM to be usable, we should reduce that 5% failure rate, rather than increase it. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
