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