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 for multiple singleton header fields in the DKIM signature verification process, there will not be a need to include an ugly, wasteful, and ineffective multiple listing of singleton header fields hack. Prior to the DKIM verification process being repaired, multiple listings of singleton header fields only precludes unlikely inter-domain spoofing. 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. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
