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