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: accounts(_at_)big-bank(_dot_)com (pre-pended by bad actor)
From: someone(_at_)big-isp(_dot_)com
DKIM-Signature: d=big-isp.com; h=from; ...
<misleading body content when related with "accounts(_at_)big-bank(_dot_)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 "accounts(_at_)big-bank(_dot_)com"
instead of "someone(_at_)big-isp(_dot_)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: accounts(_at_)big-bank(_dot_)com(_dot_)
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