On 11/3/10 6:28 AM, Alessandro Vesely wrote: > On 02/Nov/10 22:58, Douglas Otis wrote: > > On 11/2/10 11:47 AM, Alessandro Vesely 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.
We're in agreement. When fixed in DKIM, it would not be needed for 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! > > 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. This includes specifications lacking confirmations needed to avoid selection error exploits. > >>> 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. From: accou...@big-bank.com (pre-pended by bad actor) From: some...@big-isp.com DKIM-Signature: d=big-isp.com; h=from; ... <misleading body content when related with "accou...@big-bank.com"> Current DKIM specifications allow messages with pre-pended singleton headers to receive valid Author Domain Signature status. As such, ADSP might not offer any additional protection, since DKIM header stack selection is normally bottom-up. However, displaying or sorting might select "accou...@big-bank.com" instead of "some...@big-isp.com" when header stack selection by these processes is top-down. It does not matter how "big-bank.com" normally signs their messages! Big-bank.com is unable to prevent the exploit that uses big-isp.com, even by using ADSP with a discardable assertion! Their recipients may accept spoofing attempts based upon erroneous DKIM PASS status. These recipients may then draw incorrect conclusions based upon this erroneous DKIM PASS status. > > 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. No. You have incorrectly concluded big-bank.com controls the signature being exploited. A bad actor can exploit signatures of "big-isp.com" to deceive recipients who might see From: accou...@big-bank.com. This exploits the likely acceptance of big-isp.com's message stream, and perhaps any added general status annotations. > >> 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. ADSP depends upon DKIM PASS status. However, DKIM failed to require the needed checks against possible inclusion of pre-pended singleton header fields. > > 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. Better and more immediate protection would be achieved by requiring DKIM's verification to make necessary singleton header checks. It is not reasonable to expect all domains to alter their h= parameters to include double listings of all singleton header fields. This is wasteful of resources and, in most cases, will not directly benefit the domain making the change. > > 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. Which singleton header compliance check would inappropriately cause a DKIM signature to be considered invalid? > 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. We agree DKIM can be make more reliable. There is far greater harm caused when recipients confront a barrage of deceptive spoofing attempts, and then stop using the service. IMHO, the TPA-Label approach offers alternative authentication methods to recover most of the failures, along with the necessary control of third-party reporting. The next revision of the TPA-Label draft will include more examples and will add semantics for third-party reporting aimed at addressing the issues when attempting to restrict acceptance based upon DKIM status. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
