ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack.)

2010-11-03 14:21:56
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

<Prev in Thread] Current Thread [Next in Thread>